Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Well, the issue is precision which is affected by double-scaling (we have an integer intermediary scale). You could also tackle that by having the imed scale large (1024). Just a quick thought: double-scaling means we transform one coordinate from [a, b] to [c, d] in the driver, and then from [c, d] to [e, f] in the server, right? Here [a, b] is determined by the hardware. What if we choose [c, d] equal to [e, f] ? Then the scaling in the server would be from [e, f] to [e, f] i.e. a unit scaling, which I assume doesn't affect the precision (if it does, then we could let the server check if the scaling is a unit-scaling, and only perform the actual scaling if it is not). Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Mon, Oct 27, 2008 at 08:44:24AM +0100, Søren Hauberg wrote: Just a quick thought: double-scaling means we transform one coordinate from [a, b] to [c, d] in the driver, and then from [c, d] to [e, f] in the server, right? Here [a, b] is determined by the hardware. What if we choose [c, d] equal to [e, f] ? Then the scaling in the server would be from [e, f] to [e, f] i.e. a unit scaling, which I assume doesn't affect the precision (if it does, then we could let the server check if the scaling is a unit-scaling, and only perform the actual scaling if it is not). uhm. we seem to be coming back round in a full circle here. As I said in an earlier email, we don't need scaling in the driver if you can specify the min/max range at startup. So in your example, you only need scaling in the driver if you want to change [c, d] at runtime. If you can just set it up to [e, f], then you can just skip the scaling altogether. Our problem is that we don't konw [a, b] at server startup, isn't it? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: On Sat, Oct 25, 2008 at 01:42:31PM +0100, Colin Guthrie wrote: Well they didn't appear to come up I'll have a look and see if I can get more info. Not being able to log in to debug it due to lack of keyboard meant I didn't really research/probe as much as I should have done... :) lshal | grep evdev should show a number of lines with input.x11_driver = evdev. These devices should all be added to the server. If they aren't there's a bug somewhere in the server. Does it work w/o any xorg.conf? I'll try and get more info. certainly lshal *does* have several entries. I'll have to see if our current system config does anything specific in this area. Now that the dri issue that's plagued me has been addressed (or rather Eric showed me the fix done a last week for it) I should be able to use this server a bit more :) (although I do have a resume from suspend issue right now which I'll report separately) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Mon, Oct 27, 2008 at 09:20:55AM +0100, Søren Hauberg wrote: Yes, not knowing [a, b] at server startup is indeed the real problem. If we want to support run-time calibration, then it simply won't be possible to fix these parameters at startup. From what I understand, it is only the driver that supports changing parameters at run-time, so support for run-time calibration requires some sort of scaling in the driver, right? correct. 2) Clutter: scaling in the driver requires more code in the driver. This will add clutter to a currently quite clean piece of code. there's a xf86ScaleAxis call, so the clutter is negligable. My previous e-mail was just saying: if we can't get around double-scaling, then we can solve the precision issue by scaling directly to [e, f] in the driver. This doesn't solve any other issues, though... some extreme numbers to illustrate the problem: say, the kernel device announces axis 0-10 (for x and y) for the touchscreen, evdev sets it up that way. Event comes in at 5/5, driver passes it on, server scales it to 512/384 (on a 1024x768 screen). now, through calibration you suddenly realise that you actually need an axis range of 400-500 (for x and y). Your axis is still set up as 0-10 though and you mustn't touch that. event comes in at 450/450, driver must scale to 5/5, driver passes it on, server scales it to 512/384. you can't directly scale to screen res, as that would not only bust Xi, but also be clipped by the server, who expects the coordinates in the axis range. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Søren Hauberg wrote: 2008/10/24 Peter Hutterer [EMAIL PROTECTED]: Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. May may want to try if you can avoid double-scaling for non-runtime calibrated devices. E.g. if calibration data from HAL/xorg.conf is OK, you can put it in the axis struct and only double-scale when runtime calibration data is different. But that's probably harder also. Cheers, Simon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: 2008/10/24 Peter Hutterer [EMAIL PROTECTED]: Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. May may want to try if you can avoid double-scaling for non-runtime calibrated devices. E.g. if calibration data from HAL/xorg.conf is OK, you can put it in the axis struct and only double-scale when runtime calibration data is different. But that's probably harder also. I assume performance really isn't an issue here. I'd say the main issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Søren Hauberg wrote: issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Well, the issue is precision which is affected by double-scaling (we have an integer intermediary scale). You could also tackle that by having the imed scale large (1024). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/26 Simon Thum [EMAIL PROTECTED]: Søren Hauberg wrote: issue is keeping the code fairly clean. I imagine that the solution you suggest will be fairly complicated, in which case I don't think it would be worth the slight performance gain. But perhaps my priorities aren't in place... Well, the issue is precision which is affected by double-scaling (we have an integer intermediary scale). You could also tackle that by having the imed scale large (1024). Precision! Ah yes, I hadn't thought about that. I'm used to using a finger with touch screens, so precision isn't really a term that's been in my mind. Thanks for pointing it out. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Sat, Oct 25, 2008 at 01:42:31PM +0100, Colin Guthrie wrote: Well they didn't appear to come up I'll have a look and see if I can get more info. Not being able to log in to debug it due to lack of keyboard meant I didn't really research/probe as much as I should have done... :) lshal | grep evdev should show a number of lines with input.x11_driver = evdev. These devices should all be added to the server. If they aren't there's a bug somewhere in the server. Does it work w/o any xorg.conf? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: On Fri, Oct 24, 2008 at 08:50:20AM +0200, Søren Hauberg wrote: 2008/10/24 Peter Hutterer [EMAIL PROTECTED]: Touchscreen support (courtesy of Søren) enables devices that report only BTN_TOUCH capability, but no BTN_LEFT, BTN_RIGHT, etc. Great! The only major thing left is then to be able to calibrate a touch screen. I haven't been able to come up with anything better than my original patch, which essentially did a if (is_touch_screen) transform_data_according_to_calibration () for every event. My impression is that you don't like this approach. Is that correct? I wasn't happy with it because I wanted to avoid double scaling (once in the driver, once in the server). But as I haven't found a better way to get the same thing (not w/o changing the server and XI), I'm willing to put it in. Need to have a look at it again though. While I know zilch about all this stuff, would the input redirection stuff help here? I read the article recently about how compiz is using this approach (albeit with patches that may or may not be the final way to do it). http://smspillaz.wordpress.com/2008/10/21/input-redirection-update/ -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
On Fri, Oct 24, 2008 at 11:43:03AM +0200, Søren Hauberg wrote: Yeah, I can understand that. As I think I've made quite clear in previous posts: I'm stupid. That is, I don't really know X. So, here's a stupid question [1]: the server scales from what ever the driver reports to some range. So, how does the server know the range of the input, and the range of the output? xf86InitValuatorAxisStruct() provides the server with the range. If the range is valid (i.e. min max), then the server scales absolute coordinates from the device into the min..max range. However, you can only supply this range when you initialise the device. The server does not support a change in range at runtime. To be more precise, the protocol doesn't provide a method to inform clients about this change, hence you're not allowed to touch it (the server doesn't care). The patch I suggested scaled the raw x-coordinate from the touch screen from [a_x, b_x] to [min_x, max_x], where a is the smallest value reportable by the touch screen, and b is the largest. min_x and max_x are the values available in pEvdev. It seems to me that scaling is a linear transformation, so the two scalings (in the driver and in the server) should be reducable to one scaling, by combining the parameters of the two scalings. I'm not sure of this as I don't know which parameters are used in the server. it can be combined, if you specify the correct min/max range in the config (or you let it get picked up from the kernel). Then the driver doesn't need scaling, the server does it. For calibration, that doesn't work. Or to be more precise, it only works if you restart the server with the calibrated values. Otherwise, you need a separate (duplicate) scaling mechanism in the driver. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
2008/10/24 Peter Hutterer [EMAIL PROTECTED]: it can be combined, if you specify the correct min/max range in the config (or you let it get picked up from the kernel). Then the driver doesn't need scaling, the server does it. For calibration, that doesn't work. Or to be more precise, it only works if you restart the server with the calibrated values. Otherwise, you need a separate (duplicate) scaling mechanism in the driver. Hmm, yeah then I don't see an alternative to double scaling. But, hey, as long as it only happens on touch screens then I think it'll be okay, as it doesn't happen on ordinary devices. Søren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-evdev 2.0.99.2
Peter Hutterer wrote: On Fri, Oct 24, 2008 at 10:59:25AM +0100, Colin Guthrie wrote: It seems that my usb mouse wanted to make double clicks rather than single clicks when I tried this driver. Not overly sure why! When trying to update the xserver and getting inspired by the Fedora patches, I noticed a few that related to double events and AllowEmptyInput setting. As I had AllowEmptyInput set to on, could this be responsible for turning the two single clicks events into one double click? Right, the server is picking the same device up twice (evdev + kbd/mouse). Unfortunately, only some of these patches are upstream yet. Your setup needs: 1. the xserver patch to switch the console mode to RAW (d936a423) 2. the xserver patch to enable AllowEmptyInput to TRUE (0b56b44a) 3. the patch below to disable kbd/mouse if AEI is on. This is one that would break non-linux systems and leave them without input. I need to fix that up. For now, just having a ServerLayout section in your config should do the job. Probably no config should work too, but I haven't tried that without 3. yet. Thanks for the info Peter. I did actually have the patch below already applied but had to turn AEI off to get keyboard support at KDM login. I suspect I just need to make sure I load evdev in my xorg.conf which it doesn't seem to do ATM Thanks for confirming my suspicions as to what the problem is as I can probably puzzle it out from there. Of course I'll need to sort out the DRI lockups too but that's another thread! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-evdev 2.0.99.2
evdev 2.1 RC2 Touchscreen support (courtesy of Søren) enables devices that report only BTN_TOUCH capability, but no BTN_LEFT, BTN_RIGHT, etc. Julien Cristau (1): Fix TestBit() on 64bit Peter Hutterer (6): Don't post keycodes 255. Add option GrabDevice, don't grab the device by default. Init ioctl bitmasks to 0, shuts up valgrind too. MB emulation timeout is stored as Time, make the property 32-bit too. Silence compiler warning by memsetting the struct properly. evdev 2.1 RC 2 Søren Hauberg (1): Add touchscreen support. git tag: xf86-input-evdev-2.0.99.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.99.2.tar.bz2 MD5: a248d5a7bdff4b7d9df6731cd9d42531 xf86-input-evdev-2.0.99.2.tar.bz2 SHA1: ff00e3c860a763cfd0a21c083fa8ab8f2702e1a1 xf86-input-evdev-2.0.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.99.2.tar.gz MD5: 75901095b99ff3c752cd74557c5087ce xf86-input-evdev-2.0.99.2.tar.gz SHA1: 601ba2dbcf077e84a3b8130117a07c3843180e7b xf86-input-evdev-2.0.99.2.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
