Re: evdev+hal => Too many input devices.
Brian Rogers wrote:
> Gabor Gombas wrote:
>
>> Hi,
>>
>> On Wed, Jul 22, 2009 at 02:45:32PM -0700, Brian Rogers wrote:
>>
>>
>>
>>> @@ -118,14 +113,16 @@ static void del_conn(struct work_struct *work)
>>> if (!device_is_registered(&conn->dev))
>>> return;
>>>
>>> + /* wait for child devices to go away first */
>>> while (1) {
>>> struct device *dev;
>>>
>>> - dev = device_find_child(&conn->dev, NULL, __match_tty);
>>> + dev = device_find_child(&conn->dev, NULL, __match_any);
>>> if (!dev)
>>> break;
>>> - device_move(dev, NULL, DPM_ORDER_DEV_LAST);
>>> put_device(dev);
>>> +
>>> + msleep(100);
>>> }
>>>
>>> device_del(&conn->dev);
>>>
>>>
>> Won't this cause problems for rfcomm devices (again)? This code was added
>> for the reason in the comment you've deleted: the rfcomm device can
>> remain alive long after the connection is done, and it won't go away
>> until you find & manually kill the process that holds the device open.
>>
>
> The device_move action looked obsolete to me since the comment lead me
> to believe that device_move was moving the device to the root of /sys. I
> saw the input devices, which weren't being touched there, wind up in the
> root on their own when the connection was deleted so I assumed that had
> since become automatic. But now that I look at the device_move function,
> it looks like moving to null actually deletes the device.
>
> In that case, it's probably best to just delete everything right there
> and not wait for anything to close on its own. If that doesn't create
> any problems, that's what I'll do. Thanks for bringing this up.
>
OK, that didn't work. Calling device_move with a null new_parent works
the way I initially thought it did. I don't like the idea of these
things moving right before they are deleted, and neither does HAL since
it still doesn't remove the input devices properly in this case. I think
I'll go with the original strategy to ensure everything gets removed
from the same place it was first added. And I might make it work without
polling.
The rfcomm and connection objects sticking around until some process
exits shouldn't harm anything since I believe a new connection will be
given a unique name to avoid a conflict. I'll be sure to check this.
What went wrong if the rfcomm was still inside the connection when the
connection was deleted?
Brian
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal => Too many input devices.
Gabor Gombas wrote:
> Hi,
>
> On Wed, Jul 22, 2009 at 02:45:32PM -0700, Brian Rogers wrote:
>
>
>> @@ -118,14 +113,16 @@ static void del_conn(struct work_struct *work)
>> if (!device_is_registered(&conn->dev))
>> return;
>>
>> +/* wait for child devices to go away first */
>> while (1) {
>> struct device *dev;
>>
>> -dev = device_find_child(&conn->dev, NULL, __match_tty);
>> +dev = device_find_child(&conn->dev, NULL, __match_any);
>> if (!dev)
>> break;
>> -device_move(dev, NULL, DPM_ORDER_DEV_LAST);
>> put_device(dev);
>> +
>> +msleep(100);
>> }
>>
>> device_del(&conn->dev);
>>
>
> Won't this cause problems for rfcomm devices (again)? This code was added
> for the reason in the comment you've deleted: the rfcomm device can
> remain alive long after the connection is done, and it won't go away
> until you find & manually kill the process that holds the device open.
>
The device_move action looked obsolete to me since the comment lead me
to believe that device_move was moving the device to the root of /sys. I
saw the input devices, which weren't being touched there, wind up in the
root on their own when the connection was deleted so I assumed that had
since become automatic. But now that I look at the device_move function,
it looks like moving to null actually deletes the device.
In that case, it's probably best to just delete everything right there
and not wait for anything to close on its own. If that doesn't create
any problems, that's what I'll do. Thanks for bringing this up.
Brian
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal => Too many input devices.
Łukasz Maśko wrote:
(EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse
(II) UnloadModule: "evdev"
(EE) config/hal: NewInputDeviceRequest failed (11)
The kernel is sending device removal events in the wrong order, deleting
the connection before the input device associated with the connection is
removed. Then HAL doesn't see the input device removal in the right
place. Try the attached kernel patch. I'm sending this upstream,
probably with one or two changes.
>From 2779df84b73363d309fad933b6fb00e1276e8ff7 Mon Sep 17 00:00:00 2001
From: Brian Rogers
Date: Sun, 19 Jul 2009 03:43:24 -0700
Subject: [PATCH 1/2] Bluetooth: Wait for child devices to go away before deleting a connection.
---
net/bluetooth/hci_sysfs.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 95f7a7a..ebb0d15 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -100,14 +100,9 @@ static void add_conn(struct work_struct *work)
hci_dev_hold(hdev);
}
-/*
- * The rfcomm tty device will possibly retain even when conn
- * is down, and sysfs doesn't support move zombie device,
- * so we should move the device before conn device is destroyed.
- */
-static int __match_tty(struct device *dev, void *data)
+static int __match_any(struct device *dev, void *data)
{
- return !strncmp(dev_name(dev), "rfcomm", 6);
+ return 1;
}
static void del_conn(struct work_struct *work)
@@ -118,14 +113,16 @@ static void del_conn(struct work_struct *work)
if (!device_is_registered(&conn->dev))
return;
+ /* wait for child devices to go away first */
while (1) {
struct device *dev;
- dev = device_find_child(&conn->dev, NULL, __match_tty);
+ dev = device_find_child(&conn->dev, NULL, __match_any);
if (!dev)
break;
- device_move(dev, NULL, DPM_ORDER_DEV_LAST);
put_device(dev);
+
+ msleep(100);
}
device_del(&conn->dev);
--
1.6.3.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
Barton C Massey wrote: > In message <4984a2e2.8060...@xyzw.org> you wrote: > >> I'm going to be avoiding 'git format-patch' for a while >> now... >> > > Or at least 'git send-email'. We really prefer > Git-formatted patches, so thanks for doing that. But I, like > you, like to compose my own email. > Oops, yeah. That's what I meant. 'git format-patch' is actually pretty nice. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
Maarten Maathuis wrote: On Sat, Jan 31, 2009 at 7:37 PM, Brian Rogers wrote: On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. I traced the issue back to an uninitialized condition variable in libX11 xcb code. So to anyone with mysterious freezes, this may be the fix you need. Especially if your backtrace looks like the following one: #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait=) at ../../src/xcb_io.c:141 #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, wait_for_first_event=1, current_error=0x0, current_request=0) at ../../src/xcb_io.c:166 #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at ../../src/xcb_io.c:272 #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, predicate=0x7fb79dd02a70 , arg=0x284 , data1=41943044, data2=0, data3=0) #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, return_value=0x0, n_param_values=1, param_values=0x11d2280, invocation_hint=0x7fffaa4009e0) Was there supposed to be a patch or some other hint attached to this message? Sorry, I was trying out 'git send-email' for the first time (after sending a test-run to myself). It likes to post the patch as a separate mail and I wanted to write my own message separate from the commit message. Then I guess an anti-spam measure delayed delivery of the second e-mail. I'm attaching the patch here to make sure everyone can see it. Also CC'ing Keith Packard because even though I specified him as a CC and the tool repeated a header showing both names I CC'd, it just silently dropped one of them. I'm going to be avoiding 'git format-patch' for a while now... >From 301eefc5376d039b14cf7bb027c610ee276eab33 Mon Sep 17 00:00:00 2001 From: Brian Rogers Date: Sat, 31 Jan 2009 05:24:59 -0800 Subject: [PATCH] Initialize event_notify after allocating the memory for it. An uninitialized or otherwise invalid condition variable can apparently cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine at least are freezing as a result of event_notify never being initialized. Signed-off-by: Brian Rogers --- src/xcb_disp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/xcb_disp.c b/src/xcb_disp.c index d976064..584380c 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -94,6 +94,9 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, char **fullnamep, int *scr dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); dpy->xcb->event_notify = xcondition_malloc(); + if (!dpy->xcb->event_notify) + return 0; + xcondition_init(dpy->xcb->event_notify); return !xcb_connection_has_error(c); } -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
LibX11/xcb fails to initialize something
On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. I traced the issue back to an uninitialized condition variable in libX11 xcb code. So to anyone with mysterious freezes, this may be the fix you need. Especially if your backtrace looks like the following one: #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait=) at ../../src/xcb_io.c:141 #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, wait_for_first_event=1, current_error=0x0, current_request=0) at ../../src/xcb_io.c:166 #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at ../../src/xcb_io.c:272 #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, predicate=0x7fb79dd02a70 , arg=0x284 , data1=41943044, data2=0, data3=0) #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, return_value=0x0, n_param_values=1, param_values=0x11d2280, invocation_hint=0x7fffaa4009e0) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Initialize event_notify after allocating the memory for it.
An uninitialized or otherwise invalid condition variable can apparently cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine at least are freezing as a result of event_notify never being initialized. Signed-off-by: Brian Rogers --- src/xcb_disp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/xcb_disp.c b/src/xcb_disp.c index d976064..584380c 100644 --- a/src/xcb_disp.c +++ b/src/xcb_disp.c @@ -94,6 +94,9 @@ int _XConnectXCB(Display *dpy, _Xconst char *display, char **fullnamep, int *scr dpy->xcb->next_xid = xcb_generate_id(dpy->xcb->connection); dpy->xcb->event_notify = xcondition_malloc(); + if (!dpy->xcb->event_notify) + return 0; + xcondition_init(dpy->xcb->event_notify); return !xcb_connection_has_error(c); } -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver 1.6 branch and mouse position zapping
Colin Guthrie wrote: > 'Twas brillig, and Colin Guthrie at 24/12/08 02:11 did gyre and gimble: > >> Hi, >> >> Just built the 1.6 branch + recent mesa snapshot and other such stuff. >> >> It seems to be stable enough just now, but one thing that's been >> affected is how the mouse positions itself to top-left after a certain >> operations. >> >> So far I've found odd behaviour when doing: >> * Compiz cube dragging (ctrl+alt+click and drag) >> * Compiz window moving (alt+click and drag) >> * Compiz window moving (click and drag on title bar) >> >> When this happens the mouse just jumps to the top left, but not always >> immediately. >> >> While this could easily be a compiz issue (I certainly cannot reproduce >> in metacity), I'm guessing it's related to the xserver change. I have >> also updated to the latest input-proto and other such stuff too. >> >> Is there an obvious starting point to look further into this? Or perhaps >> it's a known issue? >> > I'm thinking that there is *something* up with mouse moves generally. > Simple things like hovering the mouse over a link in firefox is also a > bit odd. Hard to describe really but it seems that the "hover" event (in > web/js event terminology) only happens when the mouse is actually > *moving* not when it's just settled over the link. > > Of course this could be unrelated :) > > Col > I'm seeing that issue, too, and I also attributed this to the xserver as well. It seems to have appeared when the 1.6 branch was put into Ubuntu Jaunty. And I'm seeing the same issue on my master branch build. Firefox seems to be detecting the hover somewhere else once the mouse stops. For example, sometimes after moving the pointer over one of the items on my bookmarks toolbar, I get the hover effect there whenever the mouse stops instead of the actual location of the pointer. Right clicking a link seems to make the issue go away for a while. I'm also noticing many odd effects with compiz and x2x is completely broken with the north/south/west/east options. So yeah, I think these are all xserver issues. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange redisplay problems with Xorg 7.4 and intel driver
Tassilo Horn wrote: > Hi all, > > I use Xorg 7.4 with the free intel driver (2.4.2) on a Lenovo/IBM > ThinkPad T61. For more than a month I suffer from heavy redisplay > problems, for example: > > - I close a window, but it's still displayed. When I move another > window over it, it'll be erased. (It's like cleaning a chalkboard.) > > - I follow a link in a webbrowser, but the old page is still > displayed. In order to see the new one, I have to move the window. > > - I compile something in a terminal and some lines are not refreshed. > Again, moving the window forces a redisplay. > I've seen this too. It's the framebuffer compression code missing some screen updates for some reason. You can solve the problem by disabling framebuffer compression. Just put this in your Device section: Option "FramebufferCompression" "off" Actually, I just found a bug filed for this: https://bugs.freedesktop.org/show_bug.cgi?id=16257 > What's interesting: Whenever I plug a second monitor and use it with > Xrandr, the problem is gone. It only occurs when I solely use the > notebooks TFT. > Yeah, that's because framebuffer compression can only work on the internal display. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
