On Thu, 2010-07-08 at 00:31 +0200, Tias wrote: > >> The other bit of the problem is defining the mouse region for the > >> pointer device. Unlike your wacom device (and similar devices) where > >> the top left point of the device is quite easier to assume as the top > >> left corner of the display, IWBs aren't so simple. > >> > >> IWBs have the image projected onto the screen which is also the pointer > >> device, but it's very unlikely that the top left corner of the projected > >> image is also at the same place as the top left corner of the screen. > >> Since the mouse pointer moves to where you place you finger on the > >> screen, it's important that this maps precisely so you can click buttons > >> and drag items without a level of hit and miss (and incorrectly buttons > >> pressed). I've even seen IWBs where the image isn't even square on the > >> IWB, and I guess this needs to be addressed too. > >> > >> Any suggestions for this? > > > > now, I haven't actually tried this myself now but I think this should work > > in a combination of the evdev calibration settings and the transformation > > matrix. > > Yes, a transformation matrix can also be used to calibrate a pointer > device (in fact, a screen restriction as you described above is a kind > of calibration). > > > the xinput_calibrator tool sets the evdev calibration to address the mapping > > issue. though that only works for the single display case. > > http://www.freedesktop.org/wiki/Software/xinput_calibrator > > Indeed, I'm not really sure what happens if you have two screens, but > only one device; perhaps it shows the GUI over the entire screen ? In > that case, a calibration will try to span both screens using the input > of your one device, which is not what you want. In the case of an IWB, I'd always have two pointer devices - my mouse and the IWB pointer device. For me, it's really about making sure that the IWB pointer is actually useful. > > regardless, you can tweak the Evdev Axis Calibration property (see evdev(4)) > > manually with xinput --set-prop to get the mapping right once you've > > restricted the area. Without a GUI that'll be trial and error. > > If its a linear transformation and calibration (a mapping of one > rectangular area to another rectangular area) then they can both be set > with the Evdev Axis Calibration setting. And here's the twist. Because most IWBs are a screen/pointer device with the 'desktop' projected onto the screen, there's no guarantee that the area shown is actually rectangular. Sadly, the people who setup these devices don't care much about getting things right, but I've seen screens that have irregular shaped projections on the screen. If the IWB pointer device is to allow you to click specific buttons or simply show the pointer where you've touched the screen, then it will be necessary to calculate where you're touching the device based on a four sided area that's not a rectangle. (Imagine a projection that's not square and the both the horizontal and vertical keystones are not correct either.) What you guys are doing is way outside my league (I'm a simple perl coder) but hopefully what I can do to help is supply you with the real world examples that need to be addressed to make this truly useful. Sadly IWBs aren't as neat and tidy as a flat panel display and a wacom style pointer device (where everything is nice a square). > > CC-ing Tias, do you think you can add this to xinput_calibrator? > > Well... there are two parts to it: > - restricting the GUI to the (part of the) screen you want to calibrate > - taking this restriction into account when calibrating > > I think the code allows for it, this is all set in lines 125-133 of > gui_x11.cpp: > http://github.com/tias/xinput_calibrator/blob/master/src/gui/gui_x11.cpp > Theoretically, if you would add a display_min_x, display_max_x, > display_min_y, display_max_y command line option, and specify the > boundaries of the GUI in it, then you could update display_width and > display_height accordingly and use the min_x/y in XCreateWindow(); the > GUI will automatically be restricted. > To make the calibration calculation work, you will then have to update > the X[] and Y[] coordinates too. If you only want to shift to the right, > then X[UL] = display_min_x + delta_x; etc would probably do. If you have > a display_max_x too, then... well then you need to do a recalibration > calculation, see calibrator.cpp, lines 75-80. The rest of the code > should need no modification. > > I currently don't have time to actually try it, but I do believe it is > possible with a not-too-big amount of work. I appreciate that this will take time, but if I can help with testing then I'm more than happy to do what I can. With minimal assistance I can usually be fairly useful. Oh, should I file bug reports for this stuff in redhat's bugzilla, or would that be pointless? Rodd -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
