* [PATCH 3/4] nl80211: Pass probe response data to drivers
From: Guy Eilam @ 2011-10-22 13:11 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
In-Reply-To: <1319289112-21896-1-git-send-email-guy@wizery.com>
Allow usermode to pass probe-response data. This data can be used as a
template probe-response offloading.
Signed-off-by: Guy Eilam <guy@wizery.com>
---
include/linux/nl80211.h | 4 ++++
include/net/cfg80211.h | 4 ++++
net/wireless/nl80211.c | 11 +++++++++++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index a436f74..6369631 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1114,6 +1114,8 @@ enum nl80211_commands {
* In addition this attribute holds a bitmap of the supported protocols
* for offloading using &enum nl80211_probe_resp_offload_support_attr.
*
+ * @NL80211_ATTR_PROBE_RESP: Probe Response template data
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1344,6 +1346,8 @@ enum nl80211_attrs {
NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT,
+ NL80211_ATTR_PROBE_RESP,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b5ddd62..eb8b8c5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -737,6 +737,8 @@ struct mpath_info {
* @ap_isolate: do not forward packets between connected stations
* @ht_opmode: HT Operation mode
* (u16 = opmode, -1 = do not change)
+ * @probe_resp_len: length of probe response template (@probe_resp)
+ * @probe_resp: probe response template (AP mode only)
*/
struct bss_parameters {
int use_cts_prot;
@@ -746,6 +748,8 @@ struct bss_parameters {
u8 basic_rates_len;
int ap_isolate;
int ht_opmode;
+ int probe_resp_len;
+ u8 *probe_resp;
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ad90ec4..aadca02 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -197,6 +197,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_TDLS_OPERATION] = { .type = NLA_U8 },
[NL80211_ATTR_TDLS_SUPPORT] = { .type = NLA_FLAG },
[NL80211_ATTR_TDLS_EXTERNAL_SETUP] = { .type = NLA_FLAG },
+ [NL80211_ATTR_PROBE_RESP] = { .type = NLA_BINARY,
+ .len = IEEE80211_MAX_DATA_LEN },
};
/* policy for the key attributes */
@@ -2978,6 +2980,15 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
params.ht_opmode =
nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
+ if (info->attrs[NL80211_ATTR_PROBE_RESP]) {
+ if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP)
+ return -EOPNOTSUPP;
+
+ params.probe_resp =
+ nla_data(info->attrs[NL80211_ATTR_PROBE_RESP]);
+ params.probe_resp_len =
+ nla_len(info->attrs[NL80211_ATTR_PROBE_RESP]);
+ }
if (!rdev->ops->change_bss)
return -EOPNOTSUPP;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/4] mac80211: Save probe response data for BSS
From: Guy Eilam @ 2011-10-22 13:11 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
In-Reply-To: <1319289112-21896-1-git-send-email-guy@wizery.com>
Allow setting a probe response template for an interface operating in
AP mode. Low level drivers are notified about changes in the probe
response template and are able to retrieve a copy of the current probe
response. This data can, for example, be uploaded to hardware as a
template.
Signed-off-by: Guy Eilam <guy@wizery.com>
---
include/net/mac80211.h | 15 +++++++++++++++
net/mac80211/cfg.c | 35 +++++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 6 +++++-
net/mac80211/tx.c | 31 +++++++++++++++++++++++++++++++
net/mac80211/util.c | 3 ++-
6 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 1c58fd7..050aa32 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -166,6 +166,7 @@ struct ieee80211_low_level_stats {
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
* @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
+ * @BSS_CHANGED_AP_PROBE_RESP: Probe Response changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -184,6 +185,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
BSS_CHANGED_SSID = 1<<15,
+ BSS_CHANGED_AP_PROBE_RESP = 1<<16,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -2662,6 +2664,19 @@ static inline struct sk_buff *ieee80211_beacon_get(struct ieee80211_hw *hw,
}
/**
+ * ieee80211_proberesp_get - retrieve a Probe Response template
+ * @hw: pointer obtained from ieee80211_alloc_hw().
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ *
+ * Creates a Probe Response template which can, for example, be uploaded to
+ * hardware. The destination address should be set by the caller.
+ *
+ * Can only be called in AP mode.
+ */
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif);
+
+/**
* ieee80211_pspoll_get - retrieve a PS Poll template
* @hw: pointer obtained from ieee80211_alloc_hw().
* @vif: &struct ieee80211_vif pointer from the add_interface callback.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3cdb4a9..e2ad3da 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1230,6 +1230,34 @@ static int ieee80211_leave_mesh(struct wiphy *wiphy, struct net_device *dev)
}
#endif
+static int ieee80211_set_probe_resp(struct ieee80211_sub_if_data *sdata,
+ u8 *resp, size_t resp_len)
+{
+ struct sk_buff *new, *old;
+
+ old = sdata->u.ap.probe_resp;
+
+ if (!resp || !resp_len)
+ return -EINVAL;
+
+ new = dev_alloc_skb(resp_len);
+ if (!new) {
+ printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
+ "response template\n", sdata->name);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(new, resp_len), resp, resp_len);
+
+ rcu_assign_pointer(sdata->u.ap.probe_resp, new);
+ synchronize_rcu();
+
+ if (old)
+ dev_kfree_skb(old);
+
+ return 0;
+}
+
static int ieee80211_change_bss(struct wiphy *wiphy,
struct net_device *dev,
struct bss_parameters *params)
@@ -1292,6 +1320,13 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_HT;
}
+ if (params->probe_resp_len > 0) {
+ int ret = ieee80211_set_probe_resp(sdata, params->probe_resp,
+ params->probe_resp_len);
+ if (!ret)
+ changed |= BSS_CHANGED_AP_PROBE_RESP;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9fa5f8a..41f2a9a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -230,6 +230,7 @@ struct beacon_data {
struct ieee80211_if_ap {
struct beacon_data __rcu *beacon;
+ struct sk_buff __rcu *probe_resp;
struct list_head vlans;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index ef741e8..74d6f79 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -450,15 +450,19 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
struct ieee80211_sub_if_data *vlan, *tmpsdata;
struct beacon_data *old_beacon =
rtnl_dereference(sdata->u.ap.beacon);
+ struct sk_buff *old_probe_resp =
+ rtnl_dereference(sdata->u.ap.probe_resp);
/* sdata_running will return false, so this will disable */
ieee80211_bss_info_change_notify(sdata,
BSS_CHANGED_BEACON_ENABLED);
- /* remove beacon */
+ /* remove beacon and probe response */
rcu_assign_pointer(sdata->u.ap.beacon, NULL);
+ rcu_assign_pointer(sdata->u.ap.probe_resp, NULL);
synchronize_rcu();
kfree(old_beacon);
+ kfree(old_probe_resp);
/* down all dependent devices, that is VLANs */
list_for_each_entry_safe(vlan, tmpsdata, &sdata->u.ap.vlans,
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ad2ee4a..1f077e2 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2414,6 +2414,37 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_beacon_get_tim);
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif)
+{
+ struct ieee80211_if_ap *ap = NULL;
+ struct sk_buff *presp = NULL, *skb = NULL;
+ struct ieee80211_hdr *hdr;
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ return NULL;
+
+ rcu_read_lock();
+
+ ap = &sdata->u.ap;
+ presp = rcu_dereference(ap->probe_resp);
+ if (!presp)
+ goto out;
+
+ skb = skb_copy(presp, GFP_ATOMIC);
+ if (!skb)
+ goto out;
+
+ hdr = (struct ieee80211_hdr *) skb->data;
+ memset(hdr->addr1, 0, sizeof(hdr->addr1));
+
+out:
+ rcu_read_unlock();
+ return skb;
+}
+EXPORT_SYMBOL(ieee80211_proberesp_get);
+
struct sk_buff *ieee80211_pspoll_get(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 7439d26..d6d3ef4 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1085,7 +1085,8 @@ int ieee80211_reconfig(struct ieee80211_local *local)
changed |= BSS_CHANGED_IBSS;
/* fall through */
case NL80211_IFTYPE_AP:
- changed |= BSS_CHANGED_SSID;
+ changed |= BSS_CHANGED_SSID |
+ BSS_CHANGED_AP_PROBE_RESP;
/* fall through */
case NL80211_IFTYPE_MESH_POINT:
changed |= BSS_CHANGED_BEACON |
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/4] mac80211: Get the probe response offloading support from the driver
From: Guy Eilam @ 2011-10-22 13:11 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
In-Reply-To: <1319289112-21896-1-git-send-email-guy@wizery.com>
Query the driver for probe response offloading support
in order to notify the userspace on the protocols supported
by the driver for offloading.
Signed-off-by: Guy Eilam <guy@wizery.com>
---
include/net/mac80211.h | 3 +++
net/mac80211/cfg.c | 9 +++++++++
net/mac80211/driver-ops.h | 11 +++++++++++
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cd108df..1c58fd7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2080,6 +2080,7 @@ enum ieee80211_frame_release_type {
* The @tids parameter is a bitmap and tells the driver which TIDs the
* frames will be on; it will at most have two bits set.
* This callback must be atomic.
+ * @get_probe_resp_offload: Get probe response offload support from driver.
*/
struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw, struct sk_buff *skb);
@@ -2206,6 +2207,8 @@ struct ieee80211_ops {
u16 tids, int num_frames,
enum ieee80211_frame_release_type reason,
bool more_data);
+ int (*get_probe_resp_offload) (struct ieee80211_hw *hw,
+ u32 *supp_protocols);
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1309bb9..3cdb4a9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2470,6 +2470,14 @@ static int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev,
return 0;
}
+static int ieee80211_get_probe_resp_offload(struct wiphy *wiphy,
+ u32 *supp_protocols)
+{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+
+ return drv_get_probe_resp_offload(local, supp_protocols);
+}
+
struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -2535,4 +2543,5 @@ struct cfg80211_ops mac80211_config_ops = {
.set_rekey_data = ieee80211_set_rekey_data,
.tdls_oper = ieee80211_tdls_oper,
.tdls_mgmt = ieee80211_tdls_mgmt,
+ .get_probe_resp_offload = ieee80211_get_probe_resp_offload,
};
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 5f165d7..cd8da74 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -701,4 +701,15 @@ drv_allow_buffered_frames(struct ieee80211_local *local,
more_data);
trace_drv_return_void(local);
}
+static inline int drv_get_probe_resp_offload(struct ieee80211_local *local,
+ u32 *supp_protocols)
+{
+ int ret = -EOPNOTSUPP;
+ might_sleep();
+ if (local->ops->get_probe_resp_offload)
+ ret = local->ops->get_probe_resp_offload(&local->hw,
+ supp_protocols);
+ return ret;
+}
+
#endif /* __MAC80211_DRIVER_OPS */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/4] nl80211: Add probe response offload attribute
From: Guy Eilam @ 2011-10-22 13:11 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
Notify the userspace of the probe response offloading
support by the driver.
Signed-off-by: Guy Eilam <guy@wizery.com>
---
include/linux/nl80211.h | 24 ++++++++++++++++++++++++
include/net/cfg80211.h | 4 ++++
net/wireless/nl80211.c | 12 ++++++++++++
3 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 9d797f2..a436f74 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1109,6 +1109,11 @@ enum nl80211_commands {
* %NL80211_CMD_TDLS_MGMT. Otherwise %NL80211_CMD_TDLS_OPER should be
* used for asking the driver to perform a TDLS operation.
*
+ * @NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT: Indicates the support
+ * of probe response offloading by the driver/firmware.
+ * In addition this attribute holds a bitmap of the supported protocols
+ * for offloading using &enum nl80211_probe_resp_offload_support_attr.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1337,6 +1342,8 @@ enum nl80211_attrs {
NL80211_ATTR_TDLS_SUPPORT,
NL80211_ATTR_TDLS_EXTERNAL_SETUP,
+ NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -2648,4 +2655,21 @@ enum nl80211_tdls_operation {
NL80211_TDLS_DISABLE_LINK,
};
+/**
+ * enum nl80211_probe_resp_offload_support_attr - definition of optional
+ * supported protocols for probe response offloading by the driver/firmware
+ * to be used with the %NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT
+ * attribute. Each enum value represents a bit in the bitmap of
+ * supported protocols.
+ *
+ * @NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS: Support for WPS ver. 1
+ * @NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS2: Support for WPS ver. 2
+ * @NL80211_PROBE_RESP_OFFLOAD_SUPPORT_P2P: Support for P2P
+ */
+enum nl80211_probe_resp_offload_support_attr {
+ NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS,
+ NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS2,
+ NL80211_PROBE_RESP_OFFLOAD_SUPPORT_P2P,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 74f4f85..b5ddd62 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1425,6 +1425,8 @@ struct cfg80211_gtk_rekey_data {
*
* @tdls_mgmt: Transmit a TDLS management frame.
* @tdls_oper: Perform a high-level TDLS operation (e.g. TDLS link setup).
+ *
+ * @get_probe_resp_offload: Get probe response offload support from driver.
*/
struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -1614,6 +1616,8 @@ struct cfg80211_ops {
u16 status_code, const u8 *buf, size_t len);
int (*tdls_oper)(struct wiphy *wiphy, struct net_device *dev,
u8 *peer, enum nl80211_tdls_operation oper);
+ int (*get_probe_resp_offload) (struct wiphy *wiphy,
+ u32 *supp_protocols);
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index edf655a..ad90ec4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -759,6 +759,18 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX,
dev->wiphy.available_antennas_rx);
+ if (dev->ops->get_probe_resp_offload) {
+ u32 supp_protocols = 0;
+ int res;
+ res = dev->ops->get_probe_resp_offload(&dev->wiphy,
+ &supp_protocols);
+ if (!res) {
+ NLA_PUT_U32(msg,
+ NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT,
+ supp_protocols);
+ }
+ }
+
if ((dev->wiphy.available_antennas_tx ||
dev->wiphy.available_antennas_rx) && dev->ops->get_antenna) {
u32 tx_ant = 0, rx_ant = 0;
--
1.7.4.1
^ permalink raw reply related
* [Bug 36934] screen corruption after running a game
From: bugzilla-daemon @ 2011-10-22 13:11 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-36934-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #14 from auxsvr@gmail.com 2011-10-22 06:11:24 PDT ---
I spoke too soon: minor, transient corruption still occurs. For example, for
some seconds the glyph "u" would disappear from the panel and some widgets
became corrupted. After a while, everything returned to normal. Maybe the
virtualbox kernel modules were causing further corruption that started
elsewhere?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] jme: fix irq storm after suspend/resume
From: Mohammed Shafi @ 2011-10-22 13:09 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Guo-Fu Tseng, netdev, linux-kernel, Adrian Chadd
In-Reply-To: <20111022125620.GA2256@ecki.lan>
On Sat, Oct 22, 2011 at 6:26 PM, Clemens Buchacher <drizzd@aon.at> wrote:
> If the device is down during suspend/resume, interrupts are enabled
> without a registered interrupt handler, causing a storm of
> unhandled interrupts until the IRQ is disabled because "nobody
> cared".
thank you so much for fixing this. incredible persistence from your side!
>
> Instead, check that the device is up before touching it in the
> suspend/resume code.
>
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=39112
>
> Helped-by: Adrian Chadd <adrian@freebsd.org>
> Helped-by: Mohammed Shafi <shafi.wireless@gmail.com>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
>
> Unfortunately, bugzilla.kernel.org is still down. There is at least
> one other person who reported the issue, and I don't have their
> email address. So for now, I am the only one who tested this fix.
>
> The patch applies to current tip (2efd7c0) of Linus' tree. I also
> tested it based on v3.0 and it worked the same.
>
> Many thanks to Adrian and Mohammed for helping me debug this issue.
> See this thread for the history:
> http://mid.gmane.org/20110827113253.GA1444@ecki
>
> drivers/net/jme.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/jme.c b/drivers/net/jme.c
> index 3ac262f..7a8a3b6 100644
> --- a/drivers/net/jme.c
> +++ b/drivers/net/jme.c
> @@ -3131,6 +3131,9 @@ jme_suspend(struct device *dev)
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct jme_adapter *jme = netdev_priv(netdev);
>
> + if (!netif_running(netdev))
> + return 0;
> +
> atomic_dec(&jme->link_changing);
>
> netif_device_detach(netdev);
> @@ -3171,6 +3174,9 @@ jme_resume(struct device *dev)
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct jme_adapter *jme = netdev_priv(netdev);
>
> + if (!netif_running(netdev))
> + return 0;
> +
> jme_clear_pm(jme);
> jme_phy_on(jme);
> if (test_bit(JME_FLAG_SSET, &jme->flags))
> --
> 1.7.7
>
>
--
shafi
^ permalink raw reply
* Re: Advice on build a RAID6
From: Krzysztof Adamski @ 2011-10-22 12:57 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: linux-raid
In-Reply-To: <alpine.DEB.2.00.1110221053460.11931@uplift.swm.pp.se>
On Sat, 2011-10-22 at 10:54 +0200, Mikael Abrahamsson wrote:
> On Fri, 21 Oct 2011, Krzysztof Adamski wrote:
>
> > One requirement is to partition the drives at 99% for the RAID.
>
> Why? What problem are you solving by using partitions?
>
There are at least two, you get to control the size of the area used
instead of depending the size of the drive, if in the future you change
a drive with a different make/model that is a bit smaller, you don't
have problems then.
You can store extra information in a second partition that may help you
with future recovery.
When you have lots of drives in a box (20 to 30) it makes it easy to
tell a new drive from an existing drive by looking at the partition
table. You can't count on device names in case of problems, since
usually you would have to reboot the box specially when it hangs.
This are just a few that I can think of from my experience managing
boxes with lots of drives and MD RAID for more then last 10 years.
I know that the only downside is that the partitions have to be
correctly aligned for the 4K drives, I don't know of any other reasons
not to use partitions.
K
^ permalink raw reply
* [PATCH] python-2.6.6: Fix python-2.6.6 build failure on linux-3.x
From: ulf_samuelsson @ 2011-10-22 12:48 UTC (permalink / raw)
To: openembedded-devel; +Cc: Ulf Samuelsson
From: Ulf Samuelsson <ulf_samuelsson@telia.com>
python-2.6.6 build will crash when host is running linux kernel 3.x.
Fix backported from openembedded-core.
meta/recipes-devtools/python/python/07-linux3-regen-fix.patch
Signed-Off-By: Ulf Samuelsson <ulf.samuelsson@telia.com>
---
.../python/python-2.6.6/07-linux3-regen-fix.patch | 19 +++++++++++++++++++
recipes/python/python_2.6.6.bb | 3 ++-
2 files changed, 21 insertions(+), 1 deletions(-)
create mode 100644 recipes/python/python-2.6.6/07-linux3-regen-fix.patch
diff --git a/recipes/python/python-2.6.6/07-linux3-regen-fix.patch b/recipes/python/python-2.6.6/07-linux3-regen-fix.patch
new file mode 100644
index 0000000..ef360c5
--- /dev/null
+++ b/recipes/python/python-2.6.6/07-linux3-regen-fix.patch
@@ -0,0 +1,19 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+Without this patch it calls cross-compiled python if host is running linux-3.0
+python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
+| ./regen: line 3: /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.6.6-nk2.8/Python-2.6.6/python: cannot execute binary file
+
+diff -uNr Python-2.6.6.orig//Lib/plat-linux3/regen Python-2.6.6/Lib/plat-linux3/regen
+--- Python-2.6.6.orig//Lib/plat-linux3/regen 1970-01-01 01:00:00.000000000 +0100
++++ Python-2.6.6/Lib/plat-linux3/regen 2001-08-09 14:48:17.000000000 +0200
+@@ -0,0 +1,8 @@
++#! /bin/sh
++case `uname` in
++Linux*) ;;
++*) echo Probably not on a Linux system 1>&2
++ exit 1;;
++esac
++set -v
++h2py -i '(u_long)' /usr/include/sys/types.h /usr/include/netinet/in.h /usr/include/dlfcn.h
+
diff --git a/recipes/python/python_2.6.6.bb b/recipes/python/python_2.6.6.bb
index eacc5c2..5b47fec 100644
--- a/recipes/python/python_2.6.6.bb
+++ b/recipes/python/python_2.6.6.bb
@@ -3,7 +3,7 @@ DEPENDS = "python-native db gdbm openssl readline sqlite3 tcl zlib\
${@base_contains('DISTRO_FEATURES', 'tk', 'tk', '', d)}"
DEPENDS_sharprom = "python-native db readline zlib gdbm openssl"
# set to .0 on every increase of INC_PR
-PR = "${INC_PR}.3"
+PR = "${INC_PR}.4"
SRC_URI = "\
http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.bz2 \
@@ -14,6 +14,7 @@ SRC_URI = "\
file://04-default-is-optimized.patch \
file://05-enable-ctypes-cross-build.patch \
file://06-ctypes-libffi-fix-configure.patch \
+ file://07-linux3-regen-fix.patch \
file://ipv6-cross.patch \
file://python-module-rpath-fix.patch \
file://sitecustomize.py \
--
1.7.5.4
^ permalink raw reply related
* Re: make install not creating lib entries in /usr/lib under Ubunu 11.10
From: Ian Campbell @ 2011-10-22 12:47 UTC (permalink / raw)
To: AP; +Cc: xen-devel@lists.xensource.com, Ian Jackson
In-Reply-To: <CAGU+autjm1EEKeDjQiuwixo0QAwwNntsFWZ9V6JSTZOhyWVadg@mail.gmail.com>
On Fri, 2011-10-21 at 04:52 +0100, AP wrote:
> On Wed, Oct 19, 2011 at 8:53 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Ian Campbell writes ("Re: [Xen-devel] make install not creating lib entries in /> It might be nice if there was a single variable which could be set to
> >> control this behaviour, or even better if it can be automatically
> >> detected. I'm also inclined to suggest that the default should be to
> >> use /usr/lib and leave the lib64 thing as a RH special case, but then
> >> I'm a Debian user so I would think that ;-)
> >
> > At the very least we ought not to dump things in /usr/lib64 unless it
> > already exists and is distinct from /usr/lib.
>
> I deleted my /usr/lib64 and did a "make install-tools
> PYTHON_PREFIX_ARG=". At the end a /usr/lib64 directory was created
> with Xen related libraries inside.
I think you need to reread my earlier reply -- I explained what is going
on and provided an example of the sort of patch which fixes it. There is
no reason to expect that deleting /usr/lib64 will change anything.
Ian.
>
> > We should think about multiarch too at some point.
> >
> > Ian.
> >
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Phil Blundell @ 2011-10-22 12:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111021161620.GS3522@jama.jama.net>
On Fri, 2011-10-21 at 18:16 +0200, Martin Jansa wrote:
> On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
> > On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > > .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > index 4ac2418..2f872b8 100644
> > > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > @@ -23,3 +23,4 @@ do_compile_prepend() {
> > > cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> > > }
> > >
> > > +ARM_INSTRUCTION_SET = "arm"
> >
> > not averse to patch but it would be nice to know what fails in thumb mode.
>
> selected processor does not support Thumb mode `swp r1,r2,[r3]'
If it's only that one error (presumably some kind of home-grown atomic
operation) then let's just fix the code in question rather than forcing
the whole thing to build in ARM-state. Or if the code is hard to fix,
patch the makefile so that only the particular source files with the
assembly in are built for ARM and let the rest stay as Thumb. Making
the whole package be ARM is a bit of a heavyweight fix for that issue.
p.
^ permalink raw reply
* Re: system hangs after deleting bad file
From: hurikhan77+btrfs @ 2011-10-22 12:37 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <BwKod0ky1uB@helmut.hullen.de>
Hello Helmut!
I'm having the same observation currently: There are bad files in my $HOME
and I can't delete them because it makes the kernel ooops. I tried Josef's
repair program but it fails an assertion. What's your kernel backtrace? Did
you try the repair program? Maybe we really got the same problem and could
combine efforts? I filed an issue here:
https://github.com/josefbacik/btrfs-progs/issues/1
Helmut Hullen wrote:
> Hallo,
>
> next problem (sorry):
>
> my cluster of 3 2-TByte-disks has some damaged files. When I try to
> delete the directory entries with the "midnight commander" (via "putty",
> over the LAN) then "mc" hangs. Killing the putty session and opening
> (via "putty") a new "mc" window shows that the directory entry doesn't
> exist - looks good.
>
> Mountpoint is "/mnt/btr".
>
> lsof /mnt/btr
>
> still shows a "mc" entry which I can't remove with "killall -9 mc" or
> "kill -9 <mc-PID>".
>
> And more bad:
>
> reboot
>
> doesn't work,
>
> Ctrl Alt Delete
>
> (on the machine, not over LAN) doesn't work too.
>
> I have to restart the machine via main power switch - no good job.
^ permalink raw reply
* [PATCH] freetype_2.4.3.bb; Change order of configuration.
From: ulf_samuelsson @ 2011-10-22 12:28 UTC (permalink / raw)
To: openembedded-devel; +Cc: Ulf Samuelsson, Ulf Samuelsson
From: Ulf Samuelsson <ulf_samuelsson@telia.com>
Build of freetype-native is broken on Ubuntu 11.10 x64 - possible others.
Problem fixed in openembedded-core 2.4.4 recipe
Backporting the change will allow the build to complete.
openembedded-core-contrib/meta/recipes-graphics/freetype
Signed-Off-By: Ulf Samuelsson <ulf.samuelsson@telia.com>
---
recipes/freetype/freetype_2.4.3.bb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/recipes/freetype/freetype_2.4.3.bb b/recipes/freetype/freetype_2.4.3.bb
index 66d2e51..dfc1b43 100644
--- a/recipes/freetype/freetype_2.4.3.bb
+++ b/recipes/freetype/freetype_2.4.3.bb
@@ -1,7 +1,7 @@
DESCRIPTION = "Freetype font rendering library"
SECTION = "libs"
LICENSE = "freetype GPLv2"
-PR = "r1"
+PR = "r2"
DEPENDS = "zlib"
SRC_URI = "\
@@ -23,9 +23,9 @@ LDFLAGS_append = " -Wl,-rpath-link -Wl,${STAGING_DIR_TARGET}${libdir}"
do_configure() {
cd builds/unix
- gnu-configize --force
- aclocal -I .
libtoolize --force --copy
+ aclocal -I .
+ gnu-configize --force
autoconf
cd ${S}
oe_runconf
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] tcp: avoid frag allocation for small frames
From: Eric Dumazet @ 2011-10-22 12:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
tcp_sendmsg() uses select_size() helper to choose skb head size when a
new skb must be allocated.
If GSO is enabled for the socket, current strategy is to force all
payload data to be outside of headroom, in PAGE fragments.
This strategy is not welcome for small packets, wasting memory.
Experiments show that best results are obtained when using 2048 bytes
for skb head (This includes the skb overhead and various headers)
This patch provides better len/truesize ratios for packets sent to
loopback device, and reduce memory needs for in-flight loopback packets,
particularly on arches with big pages.
If a sender sends many 1-byte packets to an unresponsive application,
receiver rmem_alloc will grow faster and will stop queuing these packets
sooner, or will collapse its receive queue to free excess memory.
netperf -t TCP_RR results are improved by ~4 %, and many workloads are
improved as well (tbench, mysql...)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 704adad..cd45b44 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -897,9 +897,12 @@ static inline int select_size(const struct sock *sk, int sg)
int tmp = tp->mss_cache;
if (sg) {
- if (sk_can_gso(sk))
- tmp = 0;
- else {
+ if (sk_can_gso(sk)) {
+ /* Small frames wont use a full page:
+ * Payload will immediately follow tcp header.
+ */
+ tmp = SKB_WITH_OVERHEAD(2048 - MAX_TCP_HEADER);
+ } else {
int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER);
if (tmp >= pgbreak &&
^ permalink raw reply related
* [Xenomai-core] Xenomai 2.6.0-rc5
From: Gilles Chanteperdrix @ 2011-10-22 12:23 UTC (permalink / raw)
To: Xenomai help, Xenomai core
Hi,
Xenomai 2.6.0-rc5 is available at the usual place:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc5.tar.bz2
The major change since 2.6.0-rc4 is in analogy drivers sources. A new
patch for the ARM architecture was also added, for kernel 2.6.38,
including patches for imx51 and imx53 using the freescale linux-2.6-imx
git. And finally there are a few minor fixes and cosmetic changes here
and there.
Here is the shortlog:
Alexis Berlemont (1):
analogy: quick fix to keep the async buffer below 4GB
Daniele Nicolodi (3):
build: restore building of xeno-config man page
testsuite: add missing include
analogy: [ni_pcimio] replace noisy info messages by debug ones
Gilles Chanteperdrix (15):
wrappers: fix compilation of HOSTRT without TICKDEV
arm: fix context switch for linux 2.6.38
testsuite: fix xeno-regression-test help string
native: free buffer outside critical section in rt_buffer_delete
arm: fix leftover from 392989f410f10ffc228b974ffe26787dff0734f2
arm: change help message for --enable-arm-tsc option
nucleus: change default configuration
testsuite: fix regression tests location
Merge remote branch 'alex/analogy'
arm: upgrade patches
psos: long/short names issue, take #2
doc: fix README.INSTALL
testsuite: various fixes
build: bootstrap
doc: regenerate
Regards.
--
Gilles.
^ permalink raw reply
* Re: [PATCH v2 6/6] Input: wacom - 3rd gen Bamboo P&Touch packet support
From: Henrik Rydberg @ 2011-10-22 12:26 UTC (permalink / raw)
To: chris; +Cc: linux-input, dmitry.torokhov, pinglinux
In-Reply-To: <1318988593-2712-1-git-send-email-chris@cnpbagwell.com>
Hi Chris,
looks like a neat device, please find some comments below.
> 3rd generation Bamboo Pen and Touch tablets reuse the older
> stylus packet but add an extra fixed zero pad byte to end.
>
> The touch packets are quite different since it supports tracking
> of up to 16 touches. The packet is 64-byte fixed size but contains
> up to 15 smaller messages indicating data for a single touch or
> for tablet button presses.
>
> Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
> ---
>
> New in v2. There were 2 sets of indentation errors that were fixed.
> No code change. No changes in other 5 patches so only resending this
> one.
>
> drivers/input/tablet/wacom_wac.c | 94 ++++++++++++++++++++++++++++++++++++--
> drivers/input/tablet/wacom_wac.h | 4 +-
> 2 files changed, 93 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index d1ced32..13d86c5 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -836,6 +836,64 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
> return 0;
> }
>
> +static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)
> +{
> + struct input_dev *input = wacom->input;
> + int slot_id = data[0] - 2;
Are we sure slot_id < 0 cannot happen?
> + bool touch = data[1] & 0x80;
> +
> + touch = touch && !wacom->shared->stylus_in_proximity;
> +
> + input_mt_slot(input, slot_id);
> + input_mt_report_slot_state(input, MT_TOOL_FINGER, touch);
> +
> + if (touch) {
> + int x = (data[2] << 4) | (data[4] >> 4);
> + int y = (data[3] << 4) | (data[4] & 0x0f);
> + int w = data[6];
> +
> + input_report_abs(input, ABS_MT_POSITION_X, x);
> + input_report_abs(input, ABS_MT_POSITION_Y, y);
> + input_report_abs(input, ABS_MT_TOUCH_MAJOR, w);
> + }
> +}
> +
> +static void wacom_bpt3_button_msg(struct wacom_wac *wacom, unsigned char *data)
> +{
> + struct input_dev *input = wacom->input;
> +
> + input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
> + input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0);
> + input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
> + input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
> +}
> +
> +static int wacom_bpt3_touch(struct wacom_wac *wacom)
> +{
> + struct input_dev *input = wacom->input;
> + unsigned char *data = wacom->data;
> + int count = data[1] & 0x03;
> + int i;
> +
> + /* data has up to 7 fixed sized 8-byte messages starting at data[2] */
> + for (i = 0; i < count && i < 8; i++) {
The definition of count seems to imply that the test "i < 8" is unnecessary.
> + int offset = (8 * i)+2;
style problem: please use ") + 2"
> + int msg_id = data[offset];
> +
> + if (msg_id >= 2 && msg_id <= 17)
> + wacom_bpt3_touch_msg(wacom, data+offset);
ditto
> + else if (msg_id == 128)
> + wacom_bpt3_button_msg(wacom, data+offset);
ditto
> +
> + }
> +
> + input_mt_report_pointer_emulation(input, true);
> +
> + input_sync(input);
> +
> + return 0;
> +}
> +
> static int wacom_bpt_pen(struct wacom_wac *wacom)
> {
> struct input_dev *input = wacom->input;
> @@ -906,7 +964,9 @@ static int wacom_bpt_irq(struct wacom_wac *wacom, size_t len)
> {
> if (len == WACOM_PKGLEN_BBTOUCH)
> return wacom_bpt_touch(wacom);
> - else if (len == WACOM_PKGLEN_BBFUN)
> + else if (len == WACOM_PKGLEN_BBTOUCH3)
> + return wacom_bpt3_touch(wacom);
> + else if (len == WACOM_PKGLEN_BBFUN || len == WACOM_PKGLEN_BBPEN)
> return wacom_bpt_pen(wacom);
>
> return 0;
> @@ -1025,9 +1085,9 @@ void wacom_setup_device_quirks(struct wacom_features *features)
> features->type == BAMBOO_PT)
> features->quirks |= WACOM_QUIRK_MULTI_INPUT;
>
> - /* quirks for bamboo touch */
> + /* quirk for bamboo touch with 2 low res touches */
> if (features->type == BAMBOO_PT &&
> - features->device_type == BTN_TOOL_DOUBLETAP) {
> + features->pktlen == WACOM_PKGLEN_BBTOUCH) {
> features->x_max <<= 5;
> features->y_max <<= 5;
> features->x_fuzz <<= 5;
> @@ -1213,7 +1273,21 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
> __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
>
> - input_mt_init_slots(input_dev, 2);
> + if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
> + __set_bit(BTN_TOOL_TRIPLETAP,
> + input_dev->keybit);
> + __set_bit(BTN_TOOL_QUADTAP,
> + input_dev->keybit);
> +
> + input_mt_init_slots(input_dev, 16);
> +
> + input_set_abs_params(input_dev,
> + ABS_MT_TOUCH_MAJOR,
> + 0, 255, 0, 0);
> + } else {
> + input_mt_init_slots(input_dev, 2);
> + }
> +
> input_set_abs_params(input_dev, ABS_MT_POSITION_X,
> 0, features->x_max,
> features->x_fuzz, 0);
> @@ -1479,6 +1553,15 @@ static const struct wacom_features wacom_features_0xDA =
> static struct wacom_features wacom_features_0xDB =
> { "Wacom Bamboo 2FG 6x8 SE", WACOM_PKGLEN_BBFUN, 21648, 13700, 1023,
> 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> +static const struct wacom_features wacom_features_0xDD =
> + { "Wacom Bamboo Connect", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> +static const struct wacom_features wacom_features_0xDE =
> + { "Wacom Bamboo 16FG 4x5", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> +static const struct wacom_features wacom_features_0xDF =
> + { "Wacom Bamboo 16FG 6x8", WACOM_PKGLEN_BBPEN, 21648, 13700, 1023,
> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> static const struct wacom_features wacom_features_0x6004 =
> { "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
> 0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> @@ -1574,6 +1657,9 @@ const struct usb_device_id wacom_ids[] = {
> { USB_DEVICE_WACOM(0xD8) },
> { USB_DEVICE_WACOM(0xDA) },
> { USB_DEVICE_WACOM(0xDB) },
> + { USB_DEVICE_WACOM(0xDD) },
> + { USB_DEVICE_WACOM(0xDE) },
> + { USB_DEVICE_WACOM(0xDF) },
> { USB_DEVICE_WACOM(0xF0) },
> { USB_DEVICE_WACOM(0xCC) },
> { USB_DEVICE_WACOM(0x90) },
> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
> index 53eb71b..d54ffcb 100644
> --- a/drivers/input/tablet/wacom_wac.h
> +++ b/drivers/input/tablet/wacom_wac.h
> @@ -12,7 +12,7 @@
> #include <linux/types.h>
>
> /* maximum packet length for USB devices */
> -#define WACOM_PKGLEN_MAX 32
> +#define WACOM_PKGLEN_MAX 64
>
> /* packet length for individual models */
> #define WACOM_PKGLEN_PENPRTN 7
> @@ -22,6 +22,8 @@
> #define WACOM_PKGLEN_TPC1FG 5
> #define WACOM_PKGLEN_TPC2FG 14
> #define WACOM_PKGLEN_BBTOUCH 20
> +#define WACOM_PKGLEN_BBPEN 10
> +#define WACOM_PKGLEN_BBTOUCH3 64
>
> /* device IDs */
> #define STYLUS_DEVICE_ID 0x02
> --
> 1.7.6.4
Thanks,
Henrik
^ permalink raw reply
* Re: No line out on latest Mac Mini
From: Jérémy Lal @ 2011-10-22 12:18 UTC (permalink / raw)
To: John Frankish; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <654DF80AD31A344E93DBCC6280BD6DEF2226DCB3@NL0230MBX08N1.DIR.slb.com>
Hi,
i have an imac 12,2 (2011) and i had to change GPIO with hda_analyzer to get some sound
on line out.
Jérémy.
On 22/10/2011 14:14, John Frankish wrote:
> I posted this to the alsa-user list a couple of weeks ago but did not get an answer
>
> I've been trying to get analog line out to work to headphones or
> powered speakers with the latest Mac Mini, but so far the best I've
> managed to achieve is to get the internal speaker to work. Line out
> works with the Mac OS.
>
> I've also tried the HDA analyser mentioned here:
>
> http://www.alsa-project.org/main/index.php/HDA_Analyzer
>
> but no matter what I do, there is no way to get sound from the line out
> jack to headphones or powered speakers.
>
> I'm guessing I need one or more obscure options to load the module snd-hda-intel,
> but nothing I've tried so far has worked. The kernel documentation does not
> mention the mac mini 5,3 the Intel Corporation 6 Series/C200 Series Chipset nor the
> combination of Cirrus Logic CS4206 and Intel CougarPoint HDMI - does anybody know
> where I might find more details?
>
> Details below:
> ----------
> DMI: Apple Inc. Macmini5,3/Mac-7BA5B2794B2CDB12, BIOS
> MM51.88Z.0075.B00.1106271442 06/27/2011
> Alsa modules from linux-3.0.3
> Alsa-1.0.23
>
> $ lspci -knn
> 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series
> Chipset Family High Definition Audio Controller [8086:1c20] (rev 05)
> Subsystem: Intel Corporation Device [8086:7270]
> Kernel driver in use: HDA Intel
> Kernel modules: snd-hda-intel
>
> $ aplay -l
> **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel
> PCH], device 0: Cirrus Analog [Cirrus Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 1: Cirrus Digital [Cirrus Digital]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>
> $ head -n 1 /proc/asound/card0/codec*
> ==> /proc/asound/card0/codec#0 <==
> Codec: Cirrus Logic CS4206
> ==> /proc/asound/card0/codec#3 <==
> Codec: Intel CougarPoint HDMI
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* [Buildroot] [Bug 4363] Make sure that copied linux and busybox defconfig are writable before modifying
From: bugzilla at busybox.net @ 2011-10-22 12:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4363-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4363
--- Comment #1 from Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> 2011-10-22 12:17:07 UTC ---
Is it required to also modify the group permission? I'd expect u+rw to be
enough.
Moreover, can we safely assume that the read permission is already set, so that
u+w is the only thing that needs to happen?
Thirdly, the same problem is probably present for many other locations, for
example the uclibc config file, the default target skeleton (that you may want
to modify from a post-build script) etc.
To cater for your version control system (Clearcase?) all this should be fixed
as well...
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* No line out on latest Mac Mini
From: John Frankish @ 2011-10-22 12:14 UTC (permalink / raw)
To: alsa-devel@alsa-project.org
I posted this to the alsa-user list a couple of weeks ago but did not get an answer
I've been trying to get analog line out to work to headphones or
powered speakers with the latest Mac Mini, but so far the best I've
managed to achieve is to get the internal speaker to work. Line out
works with the Mac OS.
I've also tried the HDA analyser mentioned here:
http://www.alsa-project.org/main/index.php/HDA_Analyzer
but no matter what I do, there is no way to get sound from the line out
jack to headphones or powered speakers.
I'm guessing I need one or more obscure options to load the module snd-hda-intel,
but nothing I've tried so far has worked. The kernel documentation does not
mention the mac mini 5,3 the Intel Corporation 6 Series/C200 Series Chipset nor the
combination of Cirrus Logic CS4206 and Intel CougarPoint HDMI - does anybody know
where I might find more details?
Details below:
----------
DMI: Apple Inc. Macmini5,3/Mac-7BA5B2794B2CDB12, BIOS
MM51.88Z.0075.B00.1106271442 06/27/2011
Alsa modules from linux-3.0.3
Alsa-1.0.23
$ lspci -knn
00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series
Chipset Family High Definition Audio Controller [8086:1c20] (rev 05)
Subsystem: Intel Corporation Device [8086:7270]
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
$ aplay -l
**** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel
PCH], device 0: Cirrus Analog [Cirrus Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: Cirrus Digital [Cirrus Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
$ head -n 1 /proc/asound/card0/codec*
==> /proc/asound/card0/codec#0 <==
Codec: Cirrus Logic CS4206
==> /proc/asound/card0/codec#3 <==
Codec: Intel CougarPoint HDMI
^ permalink raw reply
* Unit of /proc/sys/kernel/random/poolsize
From: Tom Gundersen @ 2011-10-22 12:13 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Hi,
This might not be so much a bug report, as a request for clarification.
In random(4) it is explained that /proc/sys/kernel/random/poolsize
contains the value in bits or bytes in >=2.6 and 2.4 respectively.
However, the example in the preceding paragraph assumes a 2.4 kernel
is being used, and treats the value as if it were in bytes.
I ran across this as I maintain the initscripts for Arch Linux, where
we have been (mistakenly) following the example even though we use a
3.0 kernel. Maybe it would be worthwhile to change the example into
the 2.6 interface, or at least include a word of caution?
I realise that using a value which is too large, probably does no harm
at all, but not being cryptography expert, I'd rather not take the
chance.
Cheers,
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature addition
From: hvaibhav @ 2011-10-22 12:06 UTC (permalink / raw)
To: linux-media; +Cc: mchehab
Hi Mauro,
The following changes since commit 35a912455ff5640dc410e91279b03e04045265b2:
Mauro Carvalho Chehab (1):
Merge branch 'v4l_for_linus' into staging/for_v3.2
are available in the git repository at:
git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for-linux-media
Archit Taneja (5):
OMAP_VOUT: Fix check in reqbuf for buf_size allocation
OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
OMAP_VOUT: Add support for DSI panels
OMAP_VOUT: Increase MAX_DISPLAYS to a larger value
drivers/media/video/omap/omap_vout.c | 187 ++++++++++++++++---------------
drivers/media/video/omap/omap_voutdef.h | 2 +-
2 files changed, 97 insertions(+), 92 deletions(-)
^ permalink raw reply
* Re: [PATCH] HID: Add support for Macbook Pro 8 keyboards.
From: Henrik Rydberg @ 2011-10-22 12:04 UTC (permalink / raw)
To: Gökçen Eraslan; +Cc: Jiri Kosina, linux-input
In-Reply-To: <1319220838-3297-1-git-send-email-gokcen@pardus.org.tr>
Hi Gökçen,
looks good, except
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 7d27d2b..ffa7a85 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -112,6 +112,9 @@
> #define USB_DEVICE_ID_APPLE_ALU_REVB_ANSI 0x024f
> #define USB_DEVICE_ID_APPLE_ALU_REVB_ISO 0x0250
> #define USB_DEVICE_ID_APPLE_ALU_REVB_JIS 0x0251
> +#define USB_DEVICE_ID_APPLE_WELLSPRING5A_ANSI 0x0252
> +#define USB_DEVICE_ID_APPLE_WELLSPRING5A_ISO 0x0253
> +#define USB_DEVICE_ID_APPLE_WELLSPRING5A_JIS 0x0254
> #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI 0x0239
> #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO 0x023a
> #define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS 0x023b
which is not sorted.
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ASoC updates for 3.2
From: Takashi Iwai @ 2011-10-22 11:45 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Liam Girdwood
In-Reply-To: <20111022094957.GC3382@opensource.wolfsonmicro.com>
At Sat, 22 Oct 2011 10:49:58 +0100,
Mark Brown wrote:
>
> The following changes since commit 24441e17feb57668e4c5013750cef549bf3c4861:
>
> ASoC: ak4641: Use SND_SOC_DAPM_DAC for Voice Playback stream widget (2011-10-19 18:01:43 +0100)
>
> are available in the git repository at:
> git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-3.2
Pulled now. Thanks.
Takashi
> Ashish Chavan (2):
> ASoC: da7210: Add support for DAPM
> ASoC: da7210: Add support for line out and DAC
>
> Axel Lin (10):
> ASoC: wm9081: Fix setting soft VMID ramp enable with VMID 2*240k
> ASoC: Fix reg_word_size for ak4104
> ASoC: ak4671: Use snd_soc_update_bits for read-modify-write
> ASoC: rt5631: Remove unused codec field from struct rt5631_priv
> ASoC: wm8994: Use SND_SOC_DAPM_AIF_OUT for AIF3 Capture
> ASoC: wm8996: Use SND_SOC_DAPM_AIF_OUT for AIF2 Capture
> ASoC: Set sgtl5000->ldo in ldo_regulator_register
> ASoC: Use SGTL5000_LINREG_VDDD_MASK instead of hardcoded mask value
> ASoC: wm8996: Fix wrong mask for setting WM8996_AIF_CLOCKING_2
> ASoC: sgtl5000: Fix wrong mask in some snd_soc_update_bits calls
>
> Julia Lawall (1):
> ASoC: keep pointer to resource so it can be freed
>
> sound/soc/au1x/ac97c.c | 33 +++---
> sound/soc/au1x/i2sc.c | 33 +++---
> sound/soc/au1x/psc-ac97.c | 25 +++--
> sound/soc/au1x/psc-i2s.c | 25 +++--
> sound/soc/codecs/ak4104.c | 2 +-
> sound/soc/codecs/ak4671.c | 18 +--
> sound/soc/codecs/da7210.c | 241 ++++++++++++++++++++++++++++++++++++++-----
> sound/soc/codecs/rt5631.c | 2 -
> sound/soc/codecs/sgtl5000.c | 20 ++--
> sound/soc/codecs/wm8994.c | 2 +-
> sound/soc/codecs/wm8996.c | 6 +-
> sound/soc/codecs/wm9081.c | 2 +-
> sound/soc/mxs/mxs-saif.c | 19 ++--
> 13 files changed, 312 insertions(+), 116 deletions(-)
>
^ permalink raw reply
* Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-22 11:42 UTC (permalink / raw)
To: linux-kernel; +Cc: Jiri Kosina, linux-input, linux-usb
Short description:
An absolute pointing device using USB HID defines a LOGICAL_MINIMUM and
a LOGICAL_MAXIMUM for X, Y axes, and then sends a HID report containing
values outside that range.
Linux kernel should ignore values outside that range, as they are not
meaningful.
Just for comparison, Windows ignores such values. (and I hate this kind
of comparison)
Long description:
I'm building a homebrew USB Absolute Pointing Device using an AVR
ATmega8 and the V-USB firmware. This device will work almost like a
mouse, with one (obvious) difference: while a mouse sends "relative"
movements (move the pointer x,y units, relative to its current
position), an absolute pointing device sends "absolute" positions (move
the mouse exactly to this x,y location).
This device is using two 16-bit fields to report the X and Y axes, and
limit the meaningful values to those within the [0..32767] range. This
is the relevant part of the USB HID Descriptor:
0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x7f, // LOGICAL_MAXIMUM (32767)
0x75, 0x10, // REPORT_SIZE (16)
0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x42, // INPUT (Data,Var,Abs,Null)
However, Linux kernel is not behaving as expected when receiving
out-of-range values. Instead of ignoring such coordinates, it moves the
pointer to the bottom-right corner of the screen.
Each HID report for this device has 1 byte for the Report ID (with value
02), 2 bytes for the X position, 2 bytes for the Y position, and finally
1 byte for the button presses. They shows up as "02XXXXYY YYbb" in
usbmon.
Look at this usbmon output:
ffff88000c9a0600 1465973871 C Ii:5:093:1 0:8 6 = 02ff0fff 0f00
ffff88000c9a0600 1465973936 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1467317888 C Ii:5:093:1 0:8 6 = 02ff1fff 1f00
ffff88000c9a0600 1467317950 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1467725888 C Ii:5:093:1 0:8 6 = 02ff2fff 2f00
ffff88000c9a0600 1467725931 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1468661905 C Ii:5:093:1 0:8 6 = 02ff3fff 3f00
ffff88000c9a0600 1468661961 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1469429914 C Ii:5:093:1 0:8 6 = 02ff4fff 4f00
ffff88000c9a0600 1469429969 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1470133907 C Ii:5:093:1 0:8 6 = 02ff5fff 5f00
ffff88000c9a0600 1470133948 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1470837931 C Ii:5:093:1 0:8 6 = 02ff6fff 6f00
ffff88000c9a0600 1470837986 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1471445923 C Ii:5:093:1 0:8 6 = 02ff7fff 7f00
ffff88000c9a0600 1471445981 S Ii:5:093:1 -115:8 6 <
Here, the pointer is moving from 0x0fff, 0x0fff (near the top-left of
the screen) up to the maximum possible value: 0x7fff, 0x7fff (the
bottom-right corner). When receiving these reports, the pointer was
correctly moving diagonally across my screen.
Up until here, no problem yet. The problem starts now:
ffff88000c9a0600 1472261948 C Ii:5:093:1 0:8 6 = 02ff8fff 8f00
ffff88000c9a0600 1472262007 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1472965956 C Ii:5:093:1 0:8 6 = 02ff9fff 9f00
ffff88000c9a0600 1472966010 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1473621964 C Ii:5:093:1 0:8 6 = 02ffafff af00
ffff88000c9a0600 1473622019 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1474285972 C Ii:5:093:1 0:8 6 = 02ffbfff bf00
ffff88000c9a0600 1474286027 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1474885980 C Ii:5:093:1 0:8 6 = 02ffcfff cf00
ffff88000c9a0600 1474886034 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1475517975 C Ii:5:093:1 0:8 6 = 02ffdfff df00
ffff88000c9a0600 1475518040 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1476333997 C Ii:5:093:1 0:8 6 = 02ffefff ef00
ffff88000c9a0600 1476334055 S Ii:5:093:1 -115:8 6 <
ffff88000c9a0600 1477366011 C Ii:5:093:1 0:8 6 = 02ffffff ff00
ffff88000c9a0600 1477366069 S Ii:5:093:1 -115:8 6 <
These reports send values outside the range defined in the HID
Descriptor. The values here go from 0x8fff up to 0xffff. All of these
values are invalid and should have been ignored by the Linux kernel.
Instead, what happened was that the kernel insisted into moving the
pointer to the bottom-right corner of the screen.
Just to be sure about what I'm saying, I used my touchpad to move the
pointer away from the corner before each one of those reports, and upon
receiving them, the pointer went back to the corner.
It is worth noting that changing this:
0x81, 0x42, // INPUT (Data,Var,Abs,Null)
to this:
0x81, 0x02, // INPUT (Data,Var,Abs)
makes no difference at all.
I've also tried this device on a Windows XP system, and it works as
expected there (out-of-range values are ignored and don't move the
pointer).
It's also important to remember that an out-of-range value should be
ignored, but not the full report. For instance, the device could have
sent "02 ffff ffff 01", meaning an invalid X,Y position (which should be
ignored), but a valid button press of the first button (which should be
processed). In this case, the kernel should send a button_press event,
but not a motion event.
It may even happen to send an out-of-range value for one axis, but a
valid value for another axis. The code should be prepared for that
(ignore one, but keep the other).
Found this bug in Linux kernel 2.6.38
If someone wants to build the hardware to reproduce this bug, go to the
revision 662baa542e07 of this project:
https://bitbucket.org/denilsonsa/atmega8-magnetometer-usb-mouse/
It will probably need a few tweaks, though. Basically, after removing
the non-relevant portions of the code (sensor, menu, keyemu), it should
work using a fairly minimalistic ATmega8 circuit.
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
From: Andreas Färber @ 2011-10-22 11:36 UTC (permalink / raw)
To: khansa; +Cc: peter.maydell, riku.voipio, qemu-devel, aurelien
In-Reply-To: <1319278273-32437-6-git-send-email-khansa@kics.edu.pk>
Am 22.10.2011 12:11, schrieb khansa@kics.edu.pk:
> From: Khansa Butt <khansa@kics.edu.pk>
Commit message should mention here at least that new registers are
introduced and that load/save format is being changed.
> Signed-off-by: Khansa Butt <khansa@kics.edu.pk>
> Signed-off-by: Ehsan Ul Haq <ehsan.ulhaq@kics.edu.pk>
> Signed-off-by: Abdul Qadeer <qadeer@kics.edu.pk>
> Signed-off-by: Abdul Waheed <awaheed@kics.edu.pk>
> ---
> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> index 79e2558..9180ee9 100644
> --- a/target-mips/cpu.h
> +++ b/target-mips/cpu.h
> @@ -173,6 +173,13 @@ struct TCState {
> target_ulong CP0_TCSchedule;
> target_ulong CP0_TCScheFBack;
> int32_t CP0_Debug_tcstatus;
> + /* Multiplier registers for Octeon */
> + target_ulong MPL0;
> + target_ulong MPL1;
> + target_ulong MPL2;
> + target_ulong P0;
> + target_ulong P1;
> + target_ulong P2;
> };
>
> typedef struct CPUMIPSState CPUMIPSState;
> diff --git a/target-mips/machine.c b/target-mips/machine.c
> index be72b36..a274ce2 100644
> --- a/target-mips/machine.c
> +++ b/target-mips/machine.c
> @@ -25,6 +25,12 @@ static void save_tc(QEMUFile *f, TCState *tc)
> qemu_put_betls(f, &tc->CP0_TCSchedule);
> qemu_put_betls(f, &tc->CP0_TCScheFBack);
> qemu_put_sbe32s(f, &tc->CP0_Debug_tcstatus);
> + qemu_put_betls(f, &tc->MPL0);
> + qemu_put_betls(f, &tc->MPL1);
MPL2 is not being saved but loaded below.
> + qemu_put_betls(f, &tc->P0);
> + qemu_put_betls(f, &tc->P1);
> + qemu_put_betls(f, &tc->P2);
> +
> }
>
> static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
> @@ -173,6 +179,12 @@ static void load_tc(QEMUFile *f, TCState *tc)
> qemu_get_betls(f, &tc->CP0_TCSchedule);
> qemu_get_betls(f, &tc->CP0_TCScheFBack);
> qemu_get_sbe32s(f, &tc->CP0_Debug_tcstatus);
> + qemu_get_betls(f, &tc->MPL0);
> + qemu_get_betls(f, &tc->MPL1);
> + qemu_get_betls(f, &tc->MPL2);
> + qemu_get_betls(f, &tc->P0);
> + qemu_get_betls(f, &tc->P1);
> + qemu_get_betls(f, &tc->P2);
> }
>
> static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
You're saving new fields, so you'll need to bump the version somewhere.
For loading, since you're adding at the end, you might be able to make
your additions conditional on the to-be-bumped version.
I'm wondering whether those register and serialization additions could
and should be limited to TARGET_MIPS64.
Andreas
^ permalink raw reply
* Re: [kbd] kbd: loadkeys -d doesn't work
From: Jaroslav Skarvada @ 2011-10-22 11:35 UTC (permalink / raw)
To: Linux console tools development discussion
In-Reply-To: <4EA1F81D.3060504@gmail.com>
> 21.10.2011 18:56, Jaroslav Skarvada wrote:
> > I think it shouldn't read stdin in case of optd
>
> But in your previous email to you, do exactly the same.
> What has changed?
>
> Why behavior when the file must be different from the standard input
> handle ? I don't see any difference.
>
I tried your git head, loadkeys -d loads defkeymap as expected
but it then blocks on reading stdin. According to doc I think it
should return after the defkeymap is loaded. Sorry if I missed
anything
regards
Jaroslav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.