Re: Very strange problem with input events
Sorry if this gets not in line with the original thread: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/31159 Peter, I'm not absolutely convinced what happend then and why the problem seemed fixed, but I'm afraid the mixing-up of touchpoints was just one of multiple problems. With the latest kernel the results in mtview look o.k., but I still do get those strange effects where, as soon as I touch the touchscreen, all subsequent operations which involve clicks behave strangely (in some cases as if I had not released a mouse button or pressed another one). Could you or anyone suggest how to proceed from here? I quote a few installed libs for completeness: [ebuild R] sys-libs/mtdev-1.1.2 [ebuild R] x11-proto/inputproto-2.2 [ebuild R] x11-base/xorg-server-1.12.2 [ebuild R] x11-drivers/xf86-input-evdev-2.7.0 regards, Cedric ___ 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: Very strange problem with input events
If that helps, evtest returns the following data when I tap the screen. On Sun, Jul 08, 2012 at 01:01:16AM +0200, Cedric Sodhi wrote: Sorry if this gets not in line with the original thread: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/31159 Peter, I'm not absolutely convinced what happend then and why the problem seemed fixed, but I'm afraid the mixing-up of touchpoints was just one of multiple problems. With the latest kernel the results in mtview look o.k., but I still do get those strange effects where, as soon as I touch the touchscreen, all subsequent operations which involve clicks behave strangely (in some cases as if I had not released a mouse button or pressed another one). Could you or anyone suggest how to proceed from here? I quote a few installed libs for completeness: [ebuild R] sys-libs/mtdev-1.1.2 [ebuild R] x11-proto/inputproto-2.2 [ebuild R] x11-base/xorg-server-1.12.2 [ebuild R] x11-drivers/xf86-input-evdev-2.7.0 regards, Cedric ___ 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 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 Input device name: eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 17504 Min0 Max32767 Fuzz 7 Event code 1 (ABS_Y) Value 23472 Min0 Max32767 Fuzz 7 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max9 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32767 Fuzz 7 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32767 Fuzz 7 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1341702526.689285, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 13 Event: time 1341702526.689287, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 15680 Event: time 1341702526.689287, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 22368 Event: time 1341702526.689296, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 1341702526.689298, type 3 (EV_ABS), code 0 (ABS_X), value 15680 Event: time 1341702526.689299, type 3 (EV_ABS), code 1 (ABS_Y), value 22368 Event: time 1341702526.689299, -- SYN_REPORT Event: time 1341702526.734291, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 15664 Event: time 1341702526.734302, type 3 (EV_ABS), code 0 (ABS_X), value 15664 Event: time 1341702526.734303, -- SYN_REPORT Event: time 1341702526.762290, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1341702526.762299, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1341702526.762300, -- SYN_REPORT ___ 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: Very strange problem with input events
Besides, the problems remain after subsequently disabling the device through xinput. I think that is proof enough for the hypothesis that the problem lies in X itsself. Cedric On Sun, Jul 08, 2012 at 01:01:16AM +0200, Cedric Sodhi wrote: Sorry if this gets not in line with the original thread: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/31159 Peter, I'm not absolutely convinced what happend then and why the problem seemed fixed, but I'm afraid the mixing-up of touchpoints was just one of multiple problems. With the latest kernel the results in mtview look o.k., but I still do get those strange effects where, as soon as I touch the touchscreen, all subsequent operations which involve clicks behave strangely (in some cases as if I had not released a mouse button or pressed another one). Could you or anyone suggest how to proceed from here? I quote a few installed libs for completeness: [ebuild R] sys-libs/mtdev-1.1.2 [ebuild R] x11-proto/inputproto-2.2 [ebuild R] x11-base/xorg-server-1.12.2 [ebuild R] x11-drivers/xf86-input-evdev-2.7.0 regards, Cedric ___ 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: Very strange problem with input events
For your information, it turns out you were absolutely right, Peter, and the problem was in the kernel's input layer. It was fixed with http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=3ac36d15557d1bedfb1151d9911b9587b2d40759 mtview now gives the right feedback and the poblem in X is also resolved. best regards, Cedric On Fri, Jun 15, 2012 at 11:02:56AM +1000, Peter Hutterer wrote: On Thu, Jun 14, 2012 at 11:52:50AM +0200, Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 07:19:22PM +1000, Peter Hutterer wrote: On 14/06/12 17:35 , Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? disable the device in X with xinput and run mtview against it, that should tell you if the device misbehaves. the log looks ok on a glance. https://github.com/whot/mtview/ Ok, I think I noticed a few irregularities. Here is what I did: From the outer left and right towards the middle, I repeatedly: Put down the first finger at the righter top, dragged it down a bit. Then put down the second finger on the lefter top, and dragged both fingers down a way. Then I first took the right finger off, kept dragging a bit more downwards with the left, and then also took that one off. And did so repeatedly towards the middle of the screen. If you look carefully, you can see not onle that a single line consist of two, but really three colors! The third colored blob at the very bottom appears the moment I start over with new lines towards the middle (as consistently represented by the color). Also, on the first iteration the left finger does not appear until I raised the right finger. that's a missing feature in evemu that'll be fixed with the new version. if you're running against the current evemu release, you won't see touchpoints until the MT_SLOT value changes. Can I do anything else? fix
Re: Very strange problem with input events
On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. Just to make this clear, this has nothing to do with the touchscreen. I'm using a normal USB mouse. ___ 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: Very strange problem with input events
On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? regards, Cedric Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 Input device name: eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 22528 Min0 Max32767 Fuzz 7 Event code 1 (ABS_Y) Value 21168 Min0 Max32767 Fuzz 7 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max9 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32767 Fuzz 7 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32767 Fuzz 7 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1338794791.107562, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 16 Event: time 1338794791.107563, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 22496 Event: time 1338794791.107564, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18016 Event: time 1338794791.107573, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 1338794791.107574, type 3 (EV_ABS), code 0 (ABS_X), value 22496 Event: time 1338794791.107575, type 3 (EV_ABS), code 1 (ABS_Y), value 18016 Event: time 1338794791.107576, -- SYN_REPORT Event: time 1338794791.197575, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18032 Event: time 1338794791.197585, type 3 (EV_ABS), code 1 (ABS_Y), value 18032 Event: time 1338794791.197586, -- SYN_REPORT Event: time 1338794791.198566, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1338794791.198575, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1338794791.198576, -- SYN_REPORT
Re: XInput transform matrix
On Thu, Jun 14, 2012 at 02:43:30PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 05:46:19PM +0200, Cedric Sodhi wrote: Can anyone tell me which transform matrix (prop 133 in XI) I have to fwiw, the numerical value may be different on each machine (even on each startup), it purely depends on how many other properties were created before this one. only a handful of atoms have real fixed values, they're named XA_... (XA_ATOM, XA_CARDINAL, etc.) choose so that my touchscreen lines up with my 90 ccw rotated display? I've tried practically everything I found sensible but I got absolutly no useful results. In fact I get a jumping and flickering cursor, which also maps differently based upon which direction I move in. the rotation matrix is defined as [ cos -sin 0 ] [ sin cos 0 ] [ 00 1 ] so for a 90 degree rotation you'd use 0 -1 0 1 0 0 0 0 1. However, it's important to remember you're rotating around the origin, so if you do rotate you need to offset too, so the above example actually becomes. [ 0 -1 1 ] [ 1 0 0 ] [ 0 0 1 ] The offset is the important bit, forget about it and you get the cursor stuck in corners or edges. I had the same thoughts and came to the same conclusion, the same matrix. But I get a randomly jumping cursor then. I thought that maybe, the device (that touchscreen, again) happend to export two event devices of which I had then only rotated one, but that isn't the case. Floating the one device I tried to rotate disables it, completey. Even if the matrix were wrong, which I tink it isn't, after you just confimed it, why would the cursor jump arround like crazy? regards, Cedric ___ 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: Very strange problem with input events
On Thu, Jun 14, 2012 at 07:19:22PM +1000, Peter Hutterer wrote: On 14/06/12 17:35 , Cedric Sodhi wrote: On Thu, Jun 14, 2012 at 01:52:28PM +1000, Peter Hutterer wrote: On Wed, Jun 13, 2012 at 09:02:52PM +0200, Cedric Sodhi wrote: Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. this can only be a client issue. I can't tell you which client from here though. The drivers and the server don't deal with core vs XI events until very late. There' internal events and then based on the client selection that internal event structure is converted to the wire event and sent. So if you don't see core events, the clients haven't registered for it, or clients have otherwise registered for XI events and take precedence over core.. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. options are trying an older X servers and bisecting from a good one if you can find one. or look at the protocol with xscope to see the actual events sent on the wire (you can also use systemtap/dtrace for that but it's less pretty). For the link issue, I'd check the evtest output of the touchscreen to see if the actual device data makes sense. I take back what I said previously, that it was unrelated to the touchscreen. In fact, I narrowed down the source of the problem exactly to the touchscreen. It appears that if I do not touch the touchscreen at all, after the server has started, everything works. But as soon as I touched it at least once - thought there appears to be no sign of problems at first - these strange things (see the two examples above - I've got more examples, if you like) start happening, even if I just use the normal mouse. I had attached an evtest log of the device, do you see any indication of problems in that? disable the device in X with xinput and run mtview against it, that should tell you if the device misbehaves. the log looks ok on a glance. https://github.com/whot/mtview/ Ok, I think I noticed a few irregularities. Here is what I did: From the outer left and right towards the middle, I repeatedly: Put down the first finger at the righter top, dragged it down a bit. Then put down the second finger on the lefter top, and dragged both fingers down a way. Then I first took the right finger off, kept dragging a bit more downwards with the left, and then also took that one off. And did so repeatedly towards the middle of the screen. If you look carefully, you can see not onle that a single line consist of two, but really three colors! The third colored blob at the very bottom appears the moment I start over with new lines towards the middle (as consistently represented by the color). Also, on the first iteration the left finger does not appear until I raised the right finger. Can I do anything else? regards, Cedric ___ 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
XInput transform matrix
Can anyone tell me which transform matrix (prop 133 in XI) I have to choose so that my touchscreen lines up with my 90 ccw rotated display? I've tried practically everything I found sensible but I got absolutly no useful results. In fact I get a jumping and flickering cursor, which also maps differently based upon which direction I move in. Could you help? Thank you ___ 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
Very strange problem with input events
Unfortunally, I lack a better or just more precise description of my problem. I get strange behaviour all throughout X, everywhere clicks are involved. One thing I think I had already mentioned is that my touchscreen, which runs evdev does work properly everywhere, but there are no regular events generated - only XI events. Also, many applications strangely misbehave in a way that other people cannot possibly reproduce. Unrelated to the touchscreen, that is. Using an ordinary mouse with evdev. Two examples: Tint2 (the panel) had me drag window-icons (tasks) on the taskbar, when I clicked them, as if I had held the mouse button down. I was able to fix that by a minor change in the code of tint2, but as no one else is getting any such behaviour I assume I did not really fix the bug but only found some solution to somewhich, which fails elsewhere. I was not able to track the logic which is supposed to run, though. Second example, Midori (the browser). When I right click a hyperlink and subsequently left click an entry in the context menu, the context menu disappears (as it should) and I'm suddenly dragging the link upon which I clicked. Similar things happen everywhere else, too. I'm not even sure where to start looking. I wish I could get a suggestion from you, what to do. thank you, regards, Cedric ___ 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: Evdev for a touchscreen w/ digitizer
On Mon, Jun 04, 2012 at 09:36:10AM +0200, Cedric Sodhi wrote: On Mon, Jun 04, 2012 at 10:16:53AM +1000, Peter Hutterer wrote: On Sun, Jun 03, 2012 at 09:54:28PM +0200, Cedric Sodhi wrote: Hello, There is an EETI eGalax 0eef:a001 Touchscreen and a Wacpm 056a:0090 ISDV4 stylus device. Evtest output for a simple tap on the eGALAX is attached. With Xorg 1.12.2, inputproto 2.2 on gentoo, xinput list egalax yields eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller id=13 [slave Could you think of a reason why xinput test shows press release events but xev --root does not? It appears that applications such as Openbox require events besides the XInput events to work, so when xev --root does not show any press release events, certain things don't work. ___ 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: Evdev for a touchscreen w/ digitizer
On Tue, Jun 05, 2012 at 06:57:56PM +1000, Peter Hutterer wrote: On Tue, Jun 05, 2012 at 10:14:02AM +0200, Cedric Sodhi wrote: On Mon, Jun 04, 2012 at 09:36:10AM +0200, Cedric Sodhi wrote: On Mon, Jun 04, 2012 at 10:16:53AM +1000, Peter Hutterer wrote: On Sun, Jun 03, 2012 at 09:54:28PM +0200, Cedric Sodhi wrote: Hello, There is an EETI eGalax 0eef:a001 Touchscreen and a Wacpm 056a:0090 ISDV4 stylus device. Evtest output for a simple tap on the eGALAX is attached. With Xorg 1.12.2, inputproto 2.2 on gentoo, xinput list egalax yields eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller id=13 [slave Could you think of a reason why xinput test shows press release events but xev --root does not? It appears that applications such as Openbox require events besides the XInput events to work, so when xev --root does not show any press release events, certain things don't work. xinput --test uses XI 1.x events and they work a bit differently than core events. events are delivered from the window underneath the pointer upwards to the root window until a client selected for those events on the window. so if you run xev --root but anything below the root window selects for button events you won't see them on the root window. I suspect this is the case for you. start a plain xserver and then xev and you'll likely see the events appear on the root window. I don't know how plain it should have been, so I ran Xorg and then (from another VT) urxvt from wherein I executed xev -root. But tapping on the desktop, I still only get Motion Events. regards, Cedric ___ 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: Evdev for a touchscreen w/ digitizer
On Mon, Jun 04, 2012 at 10:16:53AM +1000, Peter Hutterer wrote: On Sun, Jun 03, 2012 at 09:54:28PM +0200, Cedric Sodhi wrote: Hello, There is an EETI eGalax 0eef:a001 Touchscreen and a Wacpm 056a:0090 ISDV4 stylus device. Evtest output for a simple tap on the eGALAX is attached. With Xorg 1.12.2, inputproto 2.2 on gentoo, xinput list egalax yields eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller id=13 [slave pointer (2)] Reporting 3 classes: Class originated from: 13 Buttons supported: 5 Button labels: Button Unknown Button Unknown Button Unknown Button Wheel Up Button Wheel Down Button state: Class originated from: 13 Detail for Valuator 0: Label: Abs MT Position X Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 640.00 Class originated from: 13 Detail for Valuator 1: Label: Abs MT Position Y Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 400.00 But there are no events reported, instead, Xorg.0.log lists [ 25099.433] [dix] eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller: unable to find touch point 0 is this logged just once or repeatedly? It used to be logged repeatedly. It no longer happens and I cannot reproduce it. However, although the pointer now moves, I get no button events. I've attached yet another log of evtest and I also CC this email to Benjamin Tissoires, who used to help me get the eGalax to work. In fact, the issue seems somewhat like the problem when the eGalax was not properly handled by the kernel. If the evtest log does not immediately reveal where the problem lies, I may bisect; but this could become rather lengthy, I don't even know whether the problem lies in evdev, in Xorg or in usb-hid. I hope you can tell by the evtest log whether the reports from the kernel are okay. Could you help? What should I do? And even if I get the eGalax to work through evdev - how do I make the Stylus take precedence over the touchscreen, so that I can rest my palm on the screen while writing, without the two devices fighting for the pointer? as I said on the linuxwacom list, this requires some sort of client-side solution. Neither the X server nor the drivers know that the two devices are interfering, to them it's just two devices used at the same time. As for that, I'll submit under a distinct subject, for I think this problem should and can be solved generically for good. Cedric Cheers, Peter Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 Input device name: eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 22528 Min0 Max32767 Fuzz 7 Event code 1 (ABS_Y) Value 21168 Min0 Max32767 Fuzz 7 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max9 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32767 Fuzz 7 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32767 Fuzz 7 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1338794791.107562, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 16 Event: time 1338794791.107563, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 22496 Event: time 1338794791.107564, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18016 Event: time 1338794791.107573, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1 Event: time 1338794791.107574, type 3 (EV_ABS), code 0 (ABS_X), value 22496 Event: time 1338794791.107575, type 3 (EV_ABS), code 1 (ABS_Y), value 18016 Event: time 1338794791.107576, -- SYN_REPORT Event: time 1338794791.197575, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 18032 Event: time 1338794791.197585, type 3 (EV_ABS), code 1 (ABS_Y), value 18032 Event: time 1338794791.197586, -- SYN_REPORT Event: time 1338794791.198566, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1338794791.198575, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1338794791.198576, -- SYN_REPORT ___ 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
Generic Precedence Grouping for Input Devices
Is it feasible to improve XI2 in a way that arbitrary pointers of devices which provide usage information (such as the proximity of wacom which tells whether the pen is actually used - i.e. in the proximity of the tablet) can be assigned priorities, so that events from devices for pointers with lower priority are ignored when ones which higher priority submit data? The concept is of course useless for any device which has no notion of usage, such as a regular mouse - but providing such means to the class of devices which do have a method of knowing that, could be consistently incorporated into the system. If we group all devices into those which do have such a capability and the rest which don't, we could distribute priorities among the former (and their multiple pointers) and a single priority for all the latter. The one priority given to all the former which do not have that capability then designates what happens if at least one of the former devices currently holds a grab and the latter (e.g. a regular mouse) emits an event. If at least one of the former holds a grab, the event from the regular mouse only comes through, if the common priority of all the latter is higher than the highest of those devices, currently holding a grab. Vice versa, the grabbing devices always take priority over the non-grabbing ones. Optionally, one may think of having the devices which do not report proximity automatically take a grab one the first event, and only release it after there has been no activitiy for a configurable time. While the solution is surely not overly elegant, it is the best thing possibly doable, as far I can see. I'm sure some would argue that such mechanism should better be implemented as part of daemon, but so I ask you: Why? Not only would this likely require different kinds of hacks, neither do I see a reason why such a rather simple mechanism shouldn't be provided by XI2 itsself. Cedric ___ 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: Evdev for a touchscreen w/ digitizer
On Mon, Jun 04, 2012 at 09:36:10AM +0200, Cedric Sodhi wrote: On Mon, Jun 04, 2012 at 10:16:53AM +1000, Peter Hutterer wrote: On Sun, Jun 03, 2012 at 09:54:28PM +0200, Cedric Sodhi wrote: Hello, There is an EETI eGalax 0eef:a001 Touchscreen and a Wacpm 056a:0090 ISDV4 stylus device. Evtest output for a simple tap on the eGALAX is attached. With Xorg 1.12.2, inputproto 2.2 on gentoo, xinput list egalax yields eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller id=13 [slave pointer (2)] Reporting 3 classes: Class originated from: 13 Buttons supported: 5 Button labels: Button Unknown Button Unknown Button Unknown Button Wheel Up Button Wheel Down Button state: Class originated from: 13 Detail for Valuator 0: Label: Abs MT Position X Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 640.00 Class originated from: 13 Detail for Valuator 1: Label: Abs MT Position Y Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 400.00 But there are no events reported, instead, Xorg.0.log lists [ 25099.433] [dix] eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller: unable to find touch point 0 is this logged just once or repeatedly? It used to be logged repeatedly. It no longer happens and I cannot reproduce it. However, although the pointer now moves, I get no button events. I've attached yet another log of evtest and I also CC this email to Benjamin Tissoires, who used to help me get the eGalax to work. In fact, the issue seems somewhat like the problem when the eGalax was not properly handled by the kernel. If the evtest log does not immediately reveal where the problem lies, I may bisect; but this could become rather lengthy, I don't even know whether the problem lies in evdev, in Xorg or in usb-hid. I hope you can tell by the evtest log whether the reports from the kernel are okay. Uhm... so, after yet another restart of X (for other reasons), although I have not changed anything, I seem now to get click events from the eGalax. Very strangely though, it does not seem to work everywhere. For example it works perfectly well in my running applications, but when I tap on the root, where Openbox would usually bring up its menu upon left click, the menu does not appear. However, if the menu is already up, clicking on it or on the root again to close it, works. All very, very strange... ___ 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
Evdev for a touchscreen w/ digitizer
Hello, There is an EETI eGalax 0eef:a001 Touchscreen and a Wacpm 056a:0090 ISDV4 stylus device. Evtest output for a simple tap on the eGALAX is attached. With Xorg 1.12.2, inputproto 2.2 on gentoo, xinput list egalax yields eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller id=13 [slave pointer (2)] Reporting 3 classes: Class originated from: 13 Buttons supported: 5 Button labels: Button Unknown Button Unknown Button Unknown Button Wheel Up Button Wheel Down Button state: Class originated from: 13 Detail for Valuator 0: Label: Abs MT Position X Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 640.00 Class originated from: 13 Detail for Valuator 1: Label: Abs MT Position Y Range: 0.00 - 32760.00 Resolution: 0 units/m Mode: absolute Current value: 400.00 But there are no events reported, instead, Xorg.0.log lists [ 25099.433] [dix] eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller: unable to find touch point 0 Could you help? What should I do? And even if I get the eGalax to work through evdev - how do I make the Stylus take precedence over the touchscreen, so that I can rest my palm on the screen while writing, without the two devices fighting for the pointer? Thank you, Cedric Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xeef product 0xa001 version 0x210 Input device name: eGalax_eMPIA Technology Inc. PCAP MultiTouch Controller Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 26816 Min0 Max32760 Fuzz 7 Event code 1 (ABS_Y) Value 14784 Min0 Max32760 Fuzz 7 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max1 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32760 Fuzz 7 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32760 Fuzz 7 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1338733218.242186, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 26160 Event: time 1338733218.242189, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 12256 Event: time 1338733218.242210, type 3 (EV_ABS), code 0 (ABS_X), value 26160 Event: time 1338733218.242212, type 3 (EV_ABS), code 1 (ABS_Y), value 12256 Event: time 1338733218.242215, -- SYN_REPORT Event: time 1338733218.305181, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 12304 Event: time 1338733218.305202, type 3 (EV_ABS), code 1 (ABS_Y), value 12304 Event: time 1338733218.305204, -- SYN_REPORT ___ 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: eGalax USB Touchscreen support it recent X.org
On Fri, Oct 28, 2011 at 08:06:02AM +1000, Peter Hutterer wrote: please file a bug, assign it to me and attach your xorg.log, xorg.conf (if any) and the evtest output for this device (bonus points for evtest-capture output so I can reproduce it here) Cheers, Peter Hello Peter, great you could reply. Can you please specify on which tracker I should file the bug, since it is not strictly a bug in the wacom driver? As promised, here is the PDF which I received from EETI. I already asked Timmy Cheng of EETI to allow me to also forward the tarbal and possibly partake in this discussion. As for evtest output (I assume the capture is included?), see my other mail. http://i.imgur.com/yJtWM.jpg -- regards, ManDay ___ 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: eGalax USB Touchscreen support it recent X.org
On Fri, Oct 28, 2011 at 11:13:49AM +0200, Cedric Sodhi wrote: On Fri, Oct 28, 2011 at 08:06:02AM +1000, Peter Hutterer wrote: please file a bug, assign it to me and attach your xorg.log, xorg.conf (if any) and the evtest output for this device (bonus points for evtest-capture output so I can reproduce it here) Cheers, Peter Hello Peter, great you could reply. Can you please specify on which tracker I should file the bug, since it is not strictly a bug in the wacom driver? Replying to myself: I did mistakingly thing your mail had come from linuxwacom. https://bugs.freedesktop.org/show_bug.cgi?id=42335 ___ 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
eGalax USB Touchscreen support it recent X.org
Hello, I've tried everything I could think of but I cannot get the eGalax Touchscreen (ASUS EEE Slate) to work. I tried various combinations of the in-kernel eGalax driver (USB Touchscreen), the USB HID Multitouch and also the Wacom driver. If I interpret it correctly USB HID always wins out, then there is /dev/input/event7 in sysfs, which responds fine and even interacts (though not correctly) with GPM. X also picks the event interface up as a touchscreen and tries to apply evdev on it, but although the cursor then moves, it remains practicablly unusuable. It's erratic at times, which I suppose happens because evdev does not sufficiently smoothen out the coordinates like, say, the xf86-input-wacom does (which is a great driver, by the way), and the coordinates to not map at all. It appears that, though XOrg says the axes were absolute, it becomes some kind of unpredictable mapping because there is also some sort of acceleration taking place. So if I, say, *touch* the screen at certain position, the cursor reproducably jumps to a specific position. But if I drag arround on the screen, there is no 1-to-1 correspondance between position on screen and position on display. Clicking also doesn't work at all. And when I try to set the evdev calibration, it has absolutly no effect whatsoever (from within xorg.conf and xinput extension cli alike). Thanks for your help. ___ 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: xf86-input-synaptics
As for 1) (Clickpad). Will these new patches happen to adress the kernel driver as well, so that we might have an option Emulate 2/3-Button presses as with ClickFinger-2-3 in the kernel? So far, using GPM is out of the question because I can only left click with that pad*. 2) Although I think Peter is making the issue seem more complicated than it is (as for detecting when a user means to hold a mod), I see his point that this is unlikely to be the responsbility of the driver. I for my part will probably go for a double click in upper left corner disabled touchpad, as it's proposed by HP. The LED would be perfect for that :P Cedric * The Hp-Clickpad has a single, strip at the bottom of the touchpad which is clickable. According to HP, the exact click should be determined by accounting for the current touch when the click is made. On Fri, May 06, 2011 at 11:04:02AM +1000, Peter Hutterer wrote: On Fri, May 06, 2011 at 01:45:18AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote: On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. do you want to enable/disable based on modifiers too? No. Why would you? only modifiers, but combos as well (ctrl+c, ctrl+v)? As above. yes. that's actually one of the rather important features. People get annoyed if they can't use their mouse cursor while holding Ctrl down, or just after ctrl+rc. but then again, what is a modifier, what if the modifier is already in use (or not in use) by a client library? IIRC gtk has a concept of consumed modifiers, so some modifiers may not qualify to disable the touchpad. long story short, we should look at making it easier and less expensive for a client to monitor keyboards and toggle functionality in other devices. Cheers, Peter do you want to only disable tapping/scrolling, but not movement? No. seriously, the options will just pile up, requiring configuration, etc. and the last thing we need is more config options and properties. I agree, but we don't have to add them. ___ 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: Does XOrg not have any proper HID support at all?
The device responds on the axes and the data is provided by X (xinput test returns a 6 dimensional motion vector), the problem is that only two axes can be CONFIGURED (for example button mapped) - at least the manual only mentions X and Y axes, mouse still had a Z-axes for scroll which was one more. I can only attach my XOrg.log in a week or so because the computer where all this setup was done is currently out of order but again, there should be no problem, certainly no errors or warnings, evdev is loaded properly without any complaints. Thanks for your reply! On 07/26/2010 12:59 AM, Peter Hutterer wrote: On Sat, Jul 24, 2010 at 04:23:50PM +0200, Cedric Sodhi wrote: Hello, the device is a SpaceNavigator by 3dconnexion. I think I'll have to revise a big part of what I said: Indeed, the device works with all its axes. That was my mistake. The problem is that the evdev driver does not support any configuration for the addinial axes, nor does it offer as many options as the original mouse driver which doesnt even account for the exinstance of the axes. The evdev driver only supports configuration for an X and a Y axis, which is 2 out of 6 axes. I can't get any of the other axes configured - that's my problem. Please attach your Xorg.log file. evdev does support up to 36 arbitrary axes and the only reason I can explain the lack of the extra axes in your case is if your device mixes relative and absolute axes. Cheers, Peter Again, sorry for the confusion, it have been some weeks since I dropped the issue and only recently I had time to mail to you so I actually forgot part of my own problem. On 07/24/2010 04:00 PM, Greg KH wrote: On Sat, Jul 24, 2010 at 12:24:05PM +0200, Cedric Sodhi wrote: Hello, this is a serious question and a serious issue, as far I can see. For the last month I've been trying all possible workarrounds an tricks I could possibly imagine to get XOrg accept a 6 Degrees Of Freedom HID compliant Input Device Works for me here, have you not used the evdev driver in xorg? The HID driver is in the kernel, not in xorg, and is not a trivial thing to implement (seriously, have you read the HID spec?) What specifically are you having problems with? What are the errors that you get. thanks, greg k-h ___ ___ 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: Does XOrg not have any proper HID support at all?
Errata: If you know a GIMP specific or any solution to it, of course I'd like to hear it! I just meant that it could distract the discussion :) On 07/26/2010 03:30 PM, Cedric Sodhi wrote: Ok, in all detail, I would not have neglected to describe the whole situation if I had known that you'd like to hear it - was just trying to keep it short, or, as I usually put it: I was trying to keep it abstract to make it as hard as possible to find a solution. ^^ In my case the application I'm doing this for is The GIMP, but please be reminded that this is just an example and you could take any other application where such problem could occur. So please, even if you know that coming versions of the GIMP solve this or know another, GIMP sepcific solution to this, don't mention it, I'm looking for a generic XOrg specific way which solves this once and for good! Particularily, I want to make a space-navigator device [1] control the view in the GIMP by MAPPING BUTTONS TO AXES, because the GIMP lacks native support to properly map axes to actions. But usually anything interactive such as panning, scrolling, etc requires configuring a specific repeat-rate and of course, the button itsself. EVDev doesn't support proper repeat rates not to mention axes beyond X and Y. I hope this became very clear now. PS: Please rule out other solutions, I've quite checked everything and X is not only the only possible options, it is also the GENERIC and THUS PREFFERED way of managing such a setup. Thanks. [1] http://www.3dconnexion.com/products/spacenavigator.html On 07/26/2010 02:11 PM, Daniel Stone wrote: (Please don't drop the list from CC.) On Mon, Jul 26, 2010 at 01:04:10PM +0200, Cedric Sodhi wrote: Yes. In more detail: Evdev does not appear to have ANY mention of other axes besides X and Y in its config - which renderes it practically a mouse driver rather than anything HID related. What _exactly_ are you trying to do? ___ 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: Does XOrg not have any proper HID support at all?
Missed to attach reference [1] http://man-wiki.net/index.php/4:evdev On 07/24/2010 12:24 PM, Cedric Sodhi wrote: Hello, this is a serious question and a serious issue, as far I can see. For the last month I've been trying all possible workarrounds an tricks I could possibly imagine to get XOrg accept a 6 Degrees Of Freedom HID compliant Input Device as Input. And after one month I stand, though more frustrated, where I stood before. Not only is there a lack of alternatives to the canonical input drivers mouse and evdev, latter, which I supposedly replacing the mousedrv is furthermore inferiour to the former and, considering the time for which HID is a widely accepted standard, poorly functional. A unindentificable and unverificable man-page which I found online [1] makes claim of far enhanced configuration for evdev but I find no trace of such capabilities anywhere on any distribution. The lack of a GENERIC HID driver, something which is widely implemented by various software (GIMP for example supports HID from a raw input stream from /dev/input out of the box - although with limited configuration) in XOrg is severe! Many devices which are designed HID compliant and are thus supposed to work out-of-the box with any contemporary operating system (not just Windows) do simply not function with X unless there is a specific Driver for the device. If I had the experience with driver programming I'd immediately get to work - it must be trivial with the readily available set of HID libraries, and I think any more experienced programmer could make a half-decent HID driver in notime - although calibration and keymapping would be mandatory - or is XInput too unflexible to handle arbitrary HID input? --MD ___ 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
Does XOrg not have any proper HID support at all?
Hello, this is a serious question and a serious issue, as far I can see. For the last month I've been trying all possible workarrounds an tricks I could possibly imagine to get XOrg accept a 6 Degrees Of Freedom HID compliant Input Device as Input. And after one month I stand, though more frustrated, where I stood before. Not only is there a lack of alternatives to the canonical input drivers mouse and evdev, latter, which I supposedly replacing the mousedrv is furthermore inferiour to the former and, considering the time for which HID is a widely accepted standard, poorly functional. A unindentificable and unverificable man-page which I found online [1] makes claim of far enhanced configuration for evdev but I find no trace of such capabilities anywhere on any distribution. The lack of a GENERIC HID driver, something which is widely implemented by various software (GIMP for example supports HID from a raw input stream from /dev/input out of the box - although with limited configuration) in XOrg is severe! Many devices which are designed HID compliant and are thus supposed to work out-of-the box with any contemporary operating system (not just Windows) do simply not function with X unless there is a specific Driver for the device. If I had the experience with driver programming I'd immediately get to work - it must be trivial with the readily available set of HID libraries, and I think any more experienced programmer could make a half-decent HID driver in notime - although calibration and keymapping would be mandatory - or is XInput too unflexible to handle arbitrary HID input? --MD ___ 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: Does XOrg not have any proper HID support at all?
Hello, the device is a SpaceNavigator by 3dconnexion. I think I'll have to revise a big part of what I said: Indeed, the device works with all its axes. That was my mistake. The problem is that the evdev driver does not support any configuration for the addinial axes, nor does it offer as many options as the original mouse driver which doesnt even account for the exinstance of the axes. The evdev driver only supports configuration for an X and a Y axis, which is 2 out of 6 axes. I can't get any of the other axes configured - that's my problem. Again, sorry for the confusion, it have been some weeks since I dropped the issue and only recently I had time to mail to you so I actually forgot part of my own problem. On 07/24/2010 04:00 PM, Greg KH wrote: On Sat, Jul 24, 2010 at 12:24:05PM +0200, Cedric Sodhi wrote: Hello, this is a serious question and a serious issue, as far I can see. For the last month I've been trying all possible workarrounds an tricks I could possibly imagine to get XOrg accept a 6 Degrees Of Freedom HID compliant Input Device Works for me here, have you not used the evdev driver in xorg? The HID driver is in the kernel, not in xorg, and is not a trivial thing to implement (seriously, have you read the HID spec?) What specifically are you having problems with? What are the errors that you get. thanks, greg k-h ___ 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
