Re: Screen corrupted every 215th pixel
On Monday 03 January 2011 22:13:23 Oldřich Jedlička wrote: Hi all, I have a really strange problem. I have every 215th column (in pixels) corrupted - when I draw two vertical lines with 214 pixels in between in Gimp and move the window on the desktop to the specific position, I don't see any line (the column is filled with the background color). I see the problem in both KDE applications and in Gimp (Gtk application), so I think this isn't a toolkit problem. When I move any window, I see something like missing columns clearly (text has no vertical line, icons miss/repeat one column). It starts on the 214th column (counted from 0) and after every 215 pixels I see the problem. Hi again, I've found one component which makes a difference - kernel. When I boot with 2.6.36 (compiled from former radeon-testing branch), everything looks good, when I boot into 2.6.37, I see the corruption. I will investigate the source of the problem and raise a bug report when I know more. The version either is the direct source or it triggers some feature that makes problems. Cheers, Oldřich. I cannot attach a screenshot, because screenshot taken with Ctrl+Printscreen shows no problem. It looks like the screen is split into stripes with 215 pixels (plus minus pixel) and every one has somethinh like off-by-one problem. I'm using this software: xorg-server-1.9.2.902 mesa Git master (r600 gallium driver) libdrm Git master xorg-video-ati Git master kernel 2.6.34-rc5, drm-next branch from airlied/drm-2.6.git qt-4.7.1 kde-4.6-rc1 gtk+-2.22.1 Does anybody know where the problem could be? Thanks, Oldrich. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Screen corrupted every 215th pixel
On Tuesday 04 January 2011 21:25:35 Oldřich Jedlička wrote: On Monday 03 January 2011 22:13:23 Oldřich Jedlička wrote: Hi all, I have a really strange problem. I have every 215th column (in pixels) corrupted - when I draw two vertical lines with 214 pixels in between in Gimp and move the window on the desktop to the specific position, I don't see any line (the column is filled with the background color). I see the problem in both KDE applications and in Gimp (Gtk application), so I think this isn't a toolkit problem. When I move any window, I see something like missing columns clearly (text has no vertical line, icons miss/repeat one column). It starts on the 214th column (counted from 0) and after every 215 pixels I see the problem. Hi again, I've found one component which makes a difference - kernel. When I boot with 2.6.36 (compiled from former radeon-testing branch), everything looks good, when I boot into 2.6.37, I see the corruption. I will investigate the source of the problem and raise a bug report when I know more. The version either is the direct source or it triggers some feature that makes problems. Ok, no. I wasn't right. It looked that everything is fine, but the corruption started to appear after I've opened Konqueror (it worked with shown Firefox). Now the corruption is on the screen aggain. The corruption affects the whole screen, so I will continue investigating. Cheers, Oldřich. I cannot attach a screenshot, because screenshot taken with Ctrl+Printscreen shows no problem. It looks like the screen is split into stripes with 215 pixels (plus minus pixel) and every one has somethinh like off-by-one problem. I'm using this software: xorg-server-1.9.2.902 mesa Git master (r600 gallium driver) libdrm Git master xorg-video-ati Git master kernel 2.6.34-rc5, drm-next branch from airlied/drm-2.6.git qt-4.7.1 kde-4.6-rc1 gtk+-2.22.1 Does anybody know where the problem could be? Thanks, Oldrich. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Screen corrupted every 215th pixel
Hi all, I have a really strange problem. I have every 215th column (in pixels) corrupted - when I draw two vertical lines with 214 pixels in between in Gimp and move the window on the desktop to the specific position, I don't see any line (the column is filled with the background color). I see the problem in both KDE applications and in Gimp (Gtk application), so I think this isn't a toolkit problem. When I move any window, I see something like missing columns clearly (text has no vertical line, icons miss/repeat one column). It starts on the 214th column (counted from 0) and after every 215 pixels I see the problem. I cannot attach a screenshot, because screenshot taken with Ctrl+Printscreen shows no problem. It looks like the screen is split into stripes with 215 pixels (plus minus pixel) and every one has somethinh like off-by-one problem. I'm using this software: xorg-server-1.9.2.902 mesa Git master (r600 gallium driver) libdrm Git master xorg-video-ati Git master kernel 2.6.34-rc5, drm-next branch from airlied/drm-2.6.git qt-4.7.1 kde-4.6-rc1 gtk+-2.22.1 Does anybody know where the problem could be? Thanks, Oldrich. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Make EVDEV a driver which is acutally useful
On Monday 30 August 2010 10:14:10 ManDay wrote: I'm deperately trying to solve a real world problem that is. Many applications do not have such sophisticated methods to use input devices (in my case: GIMP). If X/evdev gave me the option to arbitrarily remapw anything to anything (or just axes-buttons, for that matter) it would solve this problem for all these programs alltogether. the problem i see with evdev is simply that its not gerenic enough. i said that evdev has no proper support for enhanced devices because most of its options can only be used for X and Y axes and nothing beyond. Can this comment be translated to a request to have a daemon translating mouse events to key events? For example translation of some mouse axe movement to key press/release? Or any other translation for events that the application cannot handle (depends on the application)? Because as I understand it the X server provides just enough information for the application to handle the event. If the application cannot handle it, it doesn't look like an X server problem to me... I'm not an X server developper, so I actually don't know if such daemon can be easilly written (capture mouse events, detect the application that should receive it and send translated key events to that application). Maybe this is a nonsense, but those are just my 2 cents. Cheers, Oldřich. --MD On 08/30/2010 01:13 AM, Peter Hutterer wrote:/ On Fri, Aug 27, 2010 at 02:48:22PM +0200, ManDay wrote: Currently the EVDEV driver for axes-input-devices has just a few pathetic options which are at best suitable for a mouse. But since there are more input devices beyond mice and 2 axes joystick X appears to have no proper support for them, whatsoever. what's your basis for the appears to have no proper support argument? evdev takes whatever the kernel provides, labels axes accordingly and forwards events. Please provide an actual use-case of what is broken right now, I'm quite happy to get evdev fixed for that case. Since last time I contacted the list with that issue, where I was more concerned about getting a generic HID driver which can handle it all properly, people were little eager to get into that, I think I'll try with something easier which even I could try myself at. The only aim I set myself so far is supporting an arbitrary amount of axes in analogy to evdevs XYAxisMapping. That means, an arbitrary axis can emulate a button (or eky, for that matter) of one's choice. It shouldn't be too difficult, generalizing what evdev does for two axes already. why do you need this? mapping axes to buttons comes at a cost (maintaining that code) and there's a high chance that this option should rather be supported in the clients than in the driver. I hope you guys can give me tips where to start or whatever you can think of. Should I enhance the evdev driver to become more generic and support an arbitrary amount of axes or would it be better to write something like xmodmap which cannot only remap key but can also map keys/buttons to motion events? So I get a motion even, say a 6 tuple and translate it to an arbitrarily reformatted motion event plus additional keystrokes. if such a tool already exists it would be great, if not i think it will be extremely useful and can do almost anything you want, not to mention will deprecate the pathetic evdev and xmodmap. again, _why_ do you want to do this? the wording chosen make it appear like you're doing it out of academic interest, not to solve a real-world problem. I care much more about the latter than the former. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Make EVDEV a driver which is acutally useful
On Monday 30 August 2010 21:14:24 Cedric Sodhi wrote: If you talk about a mouse it sounds like you are referring to 3-DOF-at-most input devices. Please be aware that in my case I want to map, say the 5th axis. It doesn't matter which axis you want to map/translate or if you talk about mouse or any other input device (touchpad for example). I'm talking about the input event for event(s) translation done by a daemon (application running in a background). So it might be your 5th axis or anything else translated into any event (keyboard for example) that the application of your interrest can handle. Oldřich. Unless by mouse you mean motion. On 08/30/2010 09:10 PM, Oldřich Jedlička wrote: On Monday 30 August 2010 10:14:10 ManDay wrote: I'm deperately trying to solve a real world problem that is. Many applications do not have such sophisticated methods to use input devices (in my case: GIMP). If X/evdev gave me the option to arbitrarily remapw anything to anything (or just axes-buttons, for that matter) it would solve this problem for all these programs alltogether. the problem i see with evdev is simply that its not gerenic enough. i said that evdev has no proper support for enhanced devices because most of its options can only be used for X and Y axes and nothing beyond. Can this comment be translated to a request to have a daemon translating mouse events to key events? For example translation of some mouse axe movement to key press/release? Or any other translation for events that the application cannot handle (depends on the application)? Because as I understand it the X server provides just enough information for the application to handle the event. If the application cannot handle it, it doesn't look like an X server problem to me... I'm not an X server developper, so I actually don't know if such daemon can be easilly written (capture mouse events, detect the application that should receive it and send translated key events to that application). Maybe this is a nonsense, but those are just my 2 cents. Cheers, Oldřich. --MD On 08/30/2010 01:13 AM, Peter Hutterer wrote:/ On Fri, Aug 27, 2010 at 02:48:22PM +0200, ManDay wrote: Currently the EVDEV driver for axes-input-devices has just a few pathetic options which are at best suitable for a mouse. But since there are more input devices beyond mice and 2 axes joystick X appears to have no proper support for them, whatsoever. what's your basis for the appears to have no proper support argument? evdev takes whatever the kernel provides, labels axes accordingly and forwards events. Please provide an actual use-case of what is broken right now, I'm quite happy to get evdev fixed for that case. Since last time I contacted the list with that issue, where I was more concerned about getting a generic HID driver which can handle it all properly, people were little eager to get into that, I think I'll try with something easier which even I could try myself at. The only aim I set myself so far is supporting an arbitrary amount of axes in analogy to evdevs XYAxisMapping. That means, an arbitrary axis can emulate a button (or eky, for that matter) of one's choice. It shouldn't be too difficult, generalizing what evdev does for two axes already. why do you need this? mapping axes to buttons comes at a cost (maintaining that code) and there's a high chance that this option should rather be supported in the clients than in the driver. I hope you guys can give me tips where to start or whatever you can think of. Should I enhance the evdev driver to become more generic and support an arbitrary amount of axes or would it be better to write something like xmodmap which cannot only remap key but can also map keys/buttons to motion events? So I get a motion even, say a 6 tuple and translate it to an arbitrarily reformatted motion event plus additional keystrokes. if such a tool already exists it would be great, if not i think it will be extremely useful and can do almost anything you want, not to mention will deprecate the pathetic evdev and xmodmap. again, _why_ do you want to do this? the wording chosen make it appear like you're doing it out of academic interest, not to solve a real-world problem. I care much more about the latter than the former. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http
Re: Problem with mouse input freeze
Hi Peter, On Tuesday 12 of January 2010 at 03:12:15, Peter Hutterer wrote: On Fri, Jan 08, 2010 at 09:08:52PM +0100, Oldřich Jedlička wrote: Dne Pá 8. ledna 2010 07:04:34 Peter Hutterer napsal(a): On Thu, Jan 07, 2010 at 10:13:24PM +0100, Oldřich Jedlička wrote: can I assume you only have one master device and you aren't playing around with MPX? what's the output of xinput --list --short? is the pad a floating slave? I can't reproduce it here, neither on 1.7 nor on master so I might need some special setup. I will add some logging to valuators update function (the code touched in your latest patch and updateStaveDeviceCoords) in the evening, just to be sure that the valuators are updated and kept correctly. If you point me to some other place in code, I can add logging there too. I've tried KDE4 just to be sure and it works correctly there. The KDE3.5 is affected by this bug. So I don't know if it makes sense to investigate it further (if it is bug in KDE3.5/Qt or xorg). weird. the only client thing that should trigger this behaviour is a direct XI2 slave grab. KDE 3.5 can't do that though, it came out way before XI2. I might have to dig out a kde installation to reproduce that. If you can ssh in during that time, please run xinput --list --short when this happens and see if the device got detached. Hi Peter, the `xinput --list --short` is exactly the same as without the problem - attached (is it the right command?). I'm able to ssh onto the machine, so if I should do something special with gdb, I can. Just point me into the right direction :-) thanks. xinput output doesn't show anything special so jury is still out on the problem. The interesting parts to look at with gdb are: Is GetPointerEvents being called for the device? If not, it's a driver issue. what's the value of dev-public.processInputEvent? If it's EnqueueEvent, the device is frozen by some client, you need to try to identify that client. Is dev-u.master still set or NULL? if the latter, it's temporarily detached from a grab and doesn't send core events. Those are the first three I'd look at to get a clue of what the issue might be. If the device isn't frozen, step through ProcessOtherEvents and see where and why the events disappear. I've finally got to the problem analysis. The Wacom input device isn't frozen, but the master device is. I've checked the input processing and in mieqProcessDeviceEvent the dev(Wacom Intuos3 6x8)-public.processInputProc is ProcessKeyboardEvent and the master(Virtual core pointer)-public.processInputProc is EnqueueEvent (which gets called at the end of mieqProcessDeviceEvent). Is this normal? Cheers, Oldřich. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Typo in recent xf86-video-ati commit (ATOM: Upstream parser updates)
Hi Alex, On Wednesday 20 of January 2010 at 15:20:14, Alex Deucher wrote: 2010/1/20 Oldřich Jedlička oldium@seznam.cz: Hi Alex, I've just found that there are new commits in xf86-video-ati and one is suspicious to me - ATOM: Upstream parser updates. It contains lines: pParserTempData-DestData32=GetDestination[pParserTempData-ParametersTy pe.Destination](pParserTempData); pParserTempData-SourceData32=GetParametersDirect(pParserTempData); - pParserTempData-Index=GetParametersDirect(pParserTempData); + pParserTempData-Index=GetSource[pParserTempData-ParametersType.Source ](pParserTempData); Shouldn't the Index change go to SourceData32? It uses the same pattern as DestData32? No, the code is correct as is. The mask op takes two sources: an AND mask and an OR mask. The AND mask is always inline, while the OR mask is now a full param. Thanks for clarification. Oldřich. Alex ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Typo in recent xf86-video-ati commit (ATOM: Upstream parser updates)
Hi Alex, I've just found that there are new commits in xf86-video-ati and one is suspicious to me - ATOM: Upstream parser updates. It contains lines: pParserTempData-DestData32=GetDestination[pParserTempData-ParametersType.Destination](pParserTempData); pParserTempData-SourceData32=GetParametersDirect(pParserTempData); -pParserTempData-Index=GetParametersDirect(pParserTempData); + pParserTempData-Index=GetSource[pParserTempData-ParametersType.Source](pParserTempData); Shouldn't the Index change go to SourceData32? It uses the same pattern as DestData32? Cheers, Oldřich. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v3] Allow driver to call DeleteInputDeviceRequest during UnInit
When the input driver (like xf86-input-wacom) removes it's devices
during a call to UnInit, the CloseDownDevices() cannot handle it. The
next variable can become a pointer to freed memory.
The patch introduces order-independent device freeing mechanism by
remembering the already freed device ids. The devices can reorder any
time during freeing. No device will be double-freed - if the removing
failed for any reason; some implementations of DeleteInputDeviceRequest
don't free the devices already.
Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
dix/devices.c | 44 +---
1 files changed, 33 insertions(+), 11 deletions(-)
diff --git dix/devices.c dix/devices.c
index 245a95b..ef199b7 100644
--- dix/devices.c
+++ dix/devices.c
@@ -878,13 +878,43 @@ CloseDevice(DeviceIntPtr dev)
}
/**
+ * Shut down all devices of one list and free all resources.
+ */
+static
+void
+CloseDeviceList(DeviceIntPtr *listHead)
+{
+/* Used to mark devices that we tried to free */
+Bool freedIds[MAXDEVICES];
+DeviceIntPtr dev;
+int i;
+
+if (listHead == NULL)
+return;
+
+for (i = 0; i MAXDEVICES; i++)
+freedIds[i] = FALSE;
+
+dev = *listHead;
+while (dev != NULL)
+{
+freedIds[dev-id] = TRUE;
+DeleteInputDeviceRequest(dev);
+
+dev = *listHead;
+while (dev != NULL freedIds[dev-id])
+dev = dev-next;
+}
+}
+
+/**
* Shut down all devices, free all resources, etc.
* Only useful if you're shutting down the server!
*/
void
CloseDownDevices(void)
{
-DeviceIntPtr dev, next;
+DeviceIntPtr dev;
/* Float all SDs before closing them. Note that at this point resources
* (e.g. cursors) have been freed already, so we can't just call
@@ -897,16 +927,8 @@ CloseDownDevices(void)
dev-u.master = NULL;
}
-for (dev = inputInfo.devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
-for (dev = inputInfo.off_devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
+CloseDeviceList(inputInfo.devices);
+CloseDeviceList(inputInfo.off_devices);
CloseDevice(inputInfo.pointer);
CloseDevice(inputInfo.keyboard);
--
1.6.6
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] Allow driver to call DeleteInputDeviceRequest during UnInit
Hi Peter, Simon,
On Friday 15 of January 2010 at 10:40:02, Simon Thum wrote:
Oldřich Jedlička wrote:
When the input driver (like xf86-input-wacom) removes it's devices
during a call to UnInit, the CloseDownDevices() cannot handle it. The
next variable can become a pointer to freed memory.
The patch introduces order-independent device freeing mechanism by
remembering the already freed device ids. The devices can reorder any
time during freeing. No device will be double-freed - if the removing
failed for any reason; some implementations of DeleteInputDeviceRequest
don't free the devices already.
Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
dix/devices.c | 42 +++---
1 files changed, 31 insertions(+), 11 deletions(-)
diff --git dix/devices.c dix/devices.c
index 245a95b..dce0f12 100644
--- dix/devices.c
+++ dix/devices.c
@@ -878,13 +878,41 @@ CloseDevice(DeviceIntPtr dev)
}
/**
+ * Shut down all devices of one list and free all resources.
+ */
+static
+void
+CloseListDevices(DeviceIntPtr *listHead)
+{
+/* Used to mark devices that we tried to free */
+Bool freedIds[MAXDEVICES] = { 0 };
This would only work if UnInit()s removals are somehow forced onto
freedIds. In any case the freed array is a sort of context that's not
easy to get right. I'm CC'ing Peter, maybe he's got a better idea.
I was looking for an invariant and found a unique device ID. I don't know if
there is anything better for this purpose.
The closing loop works as long as those conditions are met:
1. There is no device addition during freeing (the device ID could be re-used
in such case - so that the device would not be freed). I don't know if that is
even possible.
2. No device gets enabled during the inputInfo.off_devices list closing - the
device would be moved to inputInfo.devices list which will not be iterated
again. The current implementation suffers from the same problem.
Alternative solution: I was thinking also about a different solution. Make the
DeviceInputDeviceRequest return a value (TRUE/FALSE) to indicate successful
device removal (TRUE=device is not in any of devices/off_devices list). The
lists (both?) would be iterated until there is no TRUE value returned or both
lists are empty.
What do you think? Fix-up problems mentioned in Peter's last email, or go on
with the alternative solution?
Cheers,
Oldřich.
+DeviceIntPtr dev;
+
+if (listHead == NULL)
+ return;
+
+dev = *listHead;
+while (dev != NULL)
+{
+freedIds[dev-id] = TRUE;
+DeleteInputDeviceRequest(dev);
+
+dev = *listHead;
+while (dev != NULL freedIds[dev-id])
+{
+dev = dev-next;
+}
+}
+}
+
+/**
* Shut down all devices, free all resources, etc.
* Only useful if you're shutting down the server!
*/
void
CloseDownDevices(void)
{
-DeviceIntPtr dev, next;
+DeviceIntPtr dev;
/* Float all SDs before closing them. Note that at this point
resources
* (e.g. cursors) have been freed already, so we can't just call
@@ -897,16 +925,8 @@ CloseDownDevices(void)
dev-u.master = NULL;
}
-for (dev = inputInfo.devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
-for (dev = inputInfo.off_devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
+CloseListDevices(inputInfo.devices);
+CloseListDevices(inputInfo.off_devices);
CloseDevice(inputInfo.pointer);
CloseDevice(inputInfo.keyboard);
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2] Allow driver to call DeleteInputDeviceRequest during UnInit
When the input driver (like xf86-input-wacom) removes it's devices
during a call to UnInit, the CloseDownDevices() cannot handle it. The
next variable can become a pointer to freed memory.
The patch introduces order-independent device freeing mechanism by
remembering the already freed device ids. The devices can reorder any
time during freeing. No device will be double-freed - if the removing
failed for any reason; some implementations of DeleteInputDeviceRequest
don't free the devices already.
Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
dix/devices.c | 42 +++---
1 files changed, 31 insertions(+), 11 deletions(-)
diff --git dix/devices.c dix/devices.c
index 245a95b..dce0f12 100644
--- dix/devices.c
+++ dix/devices.c
@@ -878,13 +878,41 @@ CloseDevice(DeviceIntPtr dev)
}
/**
+ * Shut down all devices of one list and free all resources.
+ */
+static
+void
+CloseListDevices(DeviceIntPtr *listHead)
+{
+/* Used to mark devices that we tried to free */
+Bool freedIds[MAXDEVICES] = { 0 };
+DeviceIntPtr dev;
+
+if (listHead == NULL)
+ return;
+
+dev = *listHead;
+while (dev != NULL)
+{
+freedIds[dev-id] = TRUE;
+DeleteInputDeviceRequest(dev);
+
+dev = *listHead;
+while (dev != NULL freedIds[dev-id])
+{
+dev = dev-next;
+}
+}
+}
+
+/**
* Shut down all devices, free all resources, etc.
* Only useful if you're shutting down the server!
*/
void
CloseDownDevices(void)
{
-DeviceIntPtr dev, next;
+DeviceIntPtr dev;
/* Float all SDs before closing them. Note that at this point resources
* (e.g. cursors) have been freed already, so we can't just call
@@ -897,16 +925,8 @@ CloseDownDevices(void)
dev-u.master = NULL;
}
-for (dev = inputInfo.devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
-for (dev = inputInfo.off_devices; dev; dev = next)
-{
- next = dev-next;
-DeleteInputDeviceRequest(dev);
-}
+CloseListDevices(inputInfo.devices);
+CloseListDevices(inputInfo.off_devices);
CloseDevice(inputInfo.pointer);
CloseDevice(inputInfo.keyboard);
--
1.6.6
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Allow driver to call DeleteInputDeviceRequest during UnInit
When an input driver (like xf86-input-wacom) removes it's devices
during a call to UnInit, the CloseDownDevices() cannot handle it. The
next variable can become a pointer to freed memory.
The patch fixes the problem by introducing a pointer to the value
holding the reference to the driver that is currently being freed.
Signed-off-by: Oldřich Jedlička oldium@seznam.cz
---
dix/devices.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index 245a95b..e4bd908 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -884,7 +884,7 @@ CloseDevice(DeviceIntPtr dev)
void
CloseDownDevices(void)
{
-DeviceIntPtr dev, next;
+DeviceIntPtr dev, *prev;
/* Float all SDs before closing them. Note that at this point resources
* (e.g. cursors) have been freed already, so we can't just call
@@ -897,15 +897,23 @@ CloseDownDevices(void)
dev-u.master = NULL;
}
-for (dev = inputInfo.devices; dev; dev = next)
+for (prev = inputInfo.devices, dev = *prev; dev; dev = *prev)
{
- next = dev-next;
DeleteInputDeviceRequest(dev);
+if (*prev == dev)
+{
+/* Device not freed, move to the next one */
+prev = dev-next;
+}
}
-for (dev = inputInfo.off_devices; dev; dev = next)
+for (prev = inputInfo.off_devices, dev = *prev; dev; dev = *prev)
{
- next = dev-next;
DeleteInputDeviceRequest(dev);
+if (*prev == dev)
+{
+/* Device not freed, move to the next one */
+prev = dev-next;
+}
}
CloseDevice(inputInfo.pointer);
--
1.6.6
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input freeze
Dne Pá 8. ledna 2010 07:04:34 Peter Hutterer napsal(a): On Thu, Jan 07, 2010 at 10:13:24PM +0100, Oldřich Jedlička wrote: can I assume you only have one master device and you aren't playing around with MPX? what's the output of xinput --list --short? is the pad a floating slave? I can't reproduce it here, neither on 1.7 nor on master so I might need some special setup. I will add some logging to valuators update function (the code touched in your latest patch and updateStaveDeviceCoords) in the evening, just to be sure that the valuators are updated and kept correctly. If you point me to some other place in code, I can add logging there too. I've tried KDE4 just to be sure and it works correctly there. The KDE3.5 is affected by this bug. So I don't know if it makes sense to investigate it further (if it is bug in KDE3.5/Qt or xorg). weird. the only client thing that should trigger this behaviour is a direct XI2 slave grab. KDE 3.5 can't do that though, it came out way before XI2. I might have to dig out a kde installation to reproduce that. If you can ssh in during that time, please run xinput --list --short when this happens and see if the device got detached. Hi Peter, the `xinput --list --short` is exactly the same as without the problem - attached (is it the right command?). I'm able to ssh onto the machine, so if I should do something special with gdb, I can. Just point me into the right direction :-) Cheers, Oldřich. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=8[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=9[slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=12 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 id=13 [slave pointer (2)] ⎜ ↳ Logitech USB RECEIVER id=14 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=6[slave keyboard (3)] ↳ i2c IR (AVerMedia Cardbus remot id=7[slave keyboard (3)] ↳ Logitech USB Receiver id=16 [slave keyboard (3)] ↳ Acer Crystal Eye webcam id=17 [slave keyboard (3)] ↳ Sleep Button id=18 [slave keyboard (3)] ↳ Video Bus id=19 [slave keyboard (3)] ↳ Power Button id=20 [slave keyboard (3)] ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input freeze
Hi Peter, Dne čtvrtek 07 Leden 2010 07:09:21 Peter Hutterer napsal(a): On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: Hi list and Peter, this is a continuation from linuxwacom-devel mailing list - the full thread (few messages actually) can be found here http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.4845 9.oldium.pro%40seznam.cz So let's start from the beginning. I had a problem: when I pressed a key on keyboard, then a PAD button on tablet that emitted a key and then a normal PAD button on the tablet, the mouse moved to [0,0] and mouse input freezed. The freeze means that mouse (tablet/ordinary mouse) moves, but there are no hover effects, no menu selection, no clicks accepted by applications - until some key is pressed. The move to [0,0] has been fixed by the patch from Peter Hutterer from this mailing list - patch with subject: [PATCH v2] dix: don't update the slave coordinates from the VCK. The mouse input freeze problem is still there, the steps to reproduce have changed: I have to press a key on keyboard, then double-click button 2 on tablet (no movement events in between - reproduced both with tablet PAD key and with tablet pen). What happens is that with only the single-click the local menu opens (but everything works); with double-click the menu opens, but doesn't go away as usual - the mouse input freezes instead (as described above). My guess is that there are still some valuators problems, so that the application grabs the mouse input and doesn't know what to do next. can I assume you only have one master device and you aren't playing around with MPX? what's the output of xinput --list --short? is the pad a floating slave? I can't reproduce it here, neither on 1.7 nor on master so I might need some special setup. I will add some logging to valuators update function (the code touched in your latest patch and updateStaveDeviceCoords) in the evening, just to be sure that the valuators are updated and kept correctly. If you point me to some other place in code, I can add logging there too. Cheers, Oldřich. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Problem with mouse input freeze
Hi list and Peter, this is a continuation from linuxwacom-devel mailing list - the full thread (few messages actually) can be found here http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.48459.oldium.pro%40seznam.cz So let's start from the beginning. I had a problem: when I pressed a key on keyboard, then a PAD button on tablet that emitted a key and then a normal PAD button on the tablet, the mouse moved to [0,0] and mouse input freezed. The freeze means that mouse (tablet/ordinary mouse) moves, but there are no hover effects, no menu selection, no clicks accepted by applications - until some key is pressed. The move to [0,0] has been fixed by the patch from Peter Hutterer from this mailing list - patch with subject: [PATCH v2] dix: don't update the slave coordinates from the VCK. The mouse input freeze problem is still there, the steps to reproduce have changed: I have to press a key on keyboard, then double-click button 2 on tablet (no movement events in between - reproduced both with tablet PAD key and with tablet pen). What happens is that with only the single-click the local menu opens (but everything works); with double-click the menu opens, but doesn't go away as usual - the mouse input freezes instead (as described above). My guess is that there are still some valuators problems, so that the application grabs the mouse input and doesn't know what to do next. Thanks for any help. Regards, Oldřich. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input freeze
Hi Peter, Dne čtvrtek 07 Leden 2010 07:09:21 Peter Hutterer napsal(a): On Wed, Jan 06, 2010 at 09:00:55PM +0100, Oldřich Jedlička wrote: Hi list and Peter, this is a continuation from linuxwacom-devel mailing list - the full thread (few messages actually) can be found here http://sourceforge.net/mailarchive/message.php?msg_name=201001022352.4845 9.oldium.pro%40seznam.cz So let's start from the beginning. I had a problem: when I pressed a key on keyboard, then a PAD button on tablet that emitted a key and then a normal PAD button on the tablet, the mouse moved to [0,0] and mouse input freezed. The freeze means that mouse (tablet/ordinary mouse) moves, but there are no hover effects, no menu selection, no clicks accepted by applications - until some key is pressed. The move to [0,0] has been fixed by the patch from Peter Hutterer from this mailing list - patch with subject: [PATCH v2] dix: don't update the slave coordinates from the VCK. The mouse input freeze problem is still there, the steps to reproduce have changed: I have to press a key on keyboard, then double-click button 2 on tablet (no movement events in between - reproduced both with tablet PAD key and with tablet pen). What happens is that with only the single-click the local menu opens (but everything works); with double-click the menu opens, but doesn't go away as usual - the mouse input freezes instead (as described above). My guess is that there are still some valuators problems, so that the application grabs the mouse input and doesn't know what to do next. can I assume you only have one master device and you aren't playing around with MPX? what's the output of xinput --list --short? is the pad a floating slave? I can't reproduce it here, neither on 1.7 nor on master so I might need some special setup. I don't have anything special (I hope), the xorg-server is installed from Gentoo package, version 1.7.3.902. It contains patch from bug 25400 (added by Gentoo) and the one I've mentioned above. Output from `xinput --list --short` is attached. I've added also my xorg.conf and Xorg.0.log. Cheers, Peter ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=8[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=9[slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=12 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 id=13 [slave pointer (2)] ⎜ ↳ Logitech USB RECEIVER id=14 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=6[slave keyboard (3)] ↳ i2c IR (AVerMedia Cardbus remot id=7[slave keyboard (3)] ↳ Logitech USB Receiver id=16 [slave keyboard (3)] ↳ Acer Crystal Eye webcam id=17 [slave keyboard (3)] ↳ Sleep Button id=18 [slave keyboard (3)] ↳ Video Bus id=19 [slave keyboard (3)] ↳ Power Button id=20 [slave keyboard (3)] This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.7.3.902 (1.7.4 RC 2) Release Date: 2009-12-26 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-drm i686 Current Operating System: Linux oldium 2.6.32-drm #5 SMP PREEMPT Mon Jan 4 00:20:21 CET 2010 i686 Kernel command line: root=/dev/sda3 gentoo=nodevfs atkbd.softraw=1 elevator=cfq lapic pci=assign-busses video=radeonfb:1024x...@75 radeon.modeset=1 Build Date: 05 January 2010 08:37:13AM Current version of pixman: 0.17.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Jan 7 08:24:18 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured
