From: Magnus V. <Mag...@ip...> - 2008-05-12 22:09:14
|
On torsdag 08 maj 2008, Daniel Stone wrote: [...] > > Calibration would add another level to this hierarchy, as would the > > possibility to define InputDevices for different areas. > > Would it? If you have any ideas for making calibration work beyond the > obvious 'allow someone to receive super-raw co-ordinates, get fed back > seven digits over the wire which you use', please let me know. I'm a > bit of a calibration novice. I don't see why it's another device rather > than just switching your input mode (device-space abs, screen-space abs, > rel, raw) and the client then grabbing and passing up seven digits when > it's satisfied. For the normal calibration process I think that would be enough. But we have a way of using a big tablet in a little more complicated way. Say you have an 12x12 inch tablet and a wide-screen monitor (and you want circles on the screen when you make circles on the tablet, not ovals). That would leave you with an area on the tablet that is not really usable.. We can add another InputDevices for a different part of the tablet and thereby use these areas. Where should we place these additional InputDevices in the hierarchy? These devices would be a case of a calibrated pen, an additional device to the normal InputDevices that would be created at normal hotplugging. In my mind the natural place for InputDevices for all areas (for 'Pen #1') would be below 'Pen #1'. > > > - Wacom tablet (catch-all master device) > > > - Pens (catch-all device) > > > - Pen #1 > > - Calibrated Pen #1 > > > - Pen #2 > > - Calibrated Pen #2 > > > - Airbrushes (catch-all device) > > > - Airbrush #1 > > - Calibrated Airbrush #1 > > > - Erasers (catch-all device) > > > > And another one here too... Should the driver send one event for each > > InputDevice all the way up to the top InputDevice for the kernel device > > or should this be handled by the xserver? Since we have transformation on > > the sent data based on the InputDevice maybe this is a driver > > responsibility. > > Nope, this will be the X server's responsibility. Parent devices won't > have real axes (being that it will be impossible to be a parent and a > child), so you just swap in the axes of the child and let the client > know that the bounds have (potentially) changed. Hmmm... This sounds MPX-ish :) 'impossible to be a parent and a child', uhm... What about the 'Pens (catch-all device)' in the example above? Wouldn't it be both? And wouldn't this actually restrict the hierarchy that a driver could create? What do we actually win on doing these changes on the parent InputDevices during event delivery? If the leaves are core-senders, what use is the same event on the parent? Couldn't we just drop the whole hierarchy in that case and have it as today? In my mind the closer to the top of the InputDevice tree you get the more 'raw' the data would become. The bounds on the axis would become more open (or rather tablet min-max, instead of the bounded area). That way the calibration process would be to open the correct InputDevice in the tree and not reset any parameters or set a specific mode. Detecting a new stylus (with a different serial id) would only be to listen on a property change event on the catch-all device for a specific tool type. And when that is received use it to define a new tool of that kind and then it's calibration time.. The bounds-changed-event is needed anyway (rotate works poorly today, the screen rotates and the client become aware of this but not that the InputDevice rotated with the screen). TabletPC needs this. > > How should we define the new InputDevices the used want instead of the > > default or on-top of the ones created default? Is it wise to have a big > > request with all parameters defined, or should there be an intemediate > > state of the InputDevice that is 'not-yet-completetly-defined' where we > > could make changes of the min-max value of the valuators (or is there an > > event for this)? > > We can create events to tell clients that axis bounds have changed, so > we just allow permanent reconfigurability. That would be both needed and nice (rotate comes to my mind). > > > > Which InputDevices in the hierarchy that will generate core events, > > > > and what the rules for setting/unsetting this core sending behaviour > > > > should be. > > > > > > Pretty much the same as it is today (DEVICE_CORE control), except that > > > it's shifted to a property. > > > > But we can't have both 'Pens (catch-all device)' and 'Calibrated Pen #2' > > sending core events at the same time, can we? > > No, because the tree has the virtual core pointer at the top, and the > parent pen device under that, and then the real pen at the bottom. So > you send one event through the server for the real pen, and then it > routes it to the appropriate clients, based on selections those clients > have made on the devices _or their parents_. In this regard, it brings > the device selection side of event delivery roughly in line with the > target selection (in terms of windows and their parents). I'm not really comfortable that you mix the pointer tree(s) with the InputDevice trees, I'd like to keep them separated. I can see a little mess coming if we do this when MPX is merged into master. Some tablets can actually report motion events for two different physical devices at the same time, so in the MPX case it might be interesting to actually split these InputDevices on different pointers. For me only a core-sending InputDevice should be allowed to be in a pointer-tree (or maybe they are allowed in the pointer tree but only core-sending InputDevices may affect the actual pointer), and there should only be one core-sending InputDevice in any given root-to-leaf path in the InputDevice tree. If a client is interested on event from a specific pointer, let it open the virtual core pointer (or MasterDevice for the specific pointer). If it's interested in events from a specific device, let it open that specific InputDevice. > > Hmmm... I honestly don't think the top-InputDevice above is suitable for > > sending core events for wacom tablets.. The Pad type is quite different > > from anything else and I'm not sure if there would be any problems if we > > start sending events in different modes (abs/rel). But lets put the > > responsibility to define which InputDevices that default should send core > > events on the driver. > > You always send absolute events in device space. Ehh.. No we don't, and we shouldn't. > The server deals with > transforms to screen space _if needed_ for you. Yes. > Likewise, it will also > deal with the conversion to relative co-ords _if needed_ for you, > depending on what the client's requested. That's the spec, but not the implementation (the relative event delivery part (unless you use the DGA-extension)), but Peter and I plan to make it so once we get axis scaling correct implemented for MPX. > This keeps the actual input > driver separate from the murky details of event delivery. Mmm... There are two different abs-rel flags that we're talking about here. Peter helped me understand this, I hope I can describe what I understood; First; the driver may report both absolute and relative coordinates to the xserver. Absolute reporting will force the connected pointer (if any) to the place on the screen that represent the place on the device. Relative reporting will move the pointer (if any) from the current position according to the delta that is reported (scaled if needed). Both are needed for a tablet. The cursor (mouse) might be more natural to have in relative mode, but it still has the possibility to report absolute if you want. Relative mode might also be the best to use of you have one tablet that you want to use on a two-monitor setup. But for me, with a 5x4 tablet and a single wide-screen monitor, absolute mode is what I want. Up to this point absolute or relative reporting is a driver issue. What the X-client will receive is another story. This is a private issue between the xserver and X-client. This is (as you say) not the problem of the InputDevice driver. [...] > > Also there is a difference between 1.3 and 1.4 in how valuator 2-max in a > > relative event is handled. 1.3 => relative, 1.4 => absolute.. (found this > > not long ago). We need to define the behaviour too.. > > I'd like to revert back to 1.3 behaviour. By the time I got around to > doing it for 1.4, it was too late to break the ABI. Honestly, I'm not sure this change was known in the first place by the drivers that reported more than two axis (Ok, evdev could be the exception).. I can't remember any change in our driver for this.. But we'll get to it when we fix this/MPX.. [...] > Yeah, definitely 3.0. It'll be either a little bit of pain during init > in particular, or driver fork time. Mmm... Here I think I let someone else decide ;) [...] > > > Does all this sound reasonable? > > > > Pretty much, yes. We should put this on the Wiki.. > > Be my guest. :) More than happy to proofread and expand anything -- grab > some space under www.x.org/wiki/Documentation or something. Ok, I'll do this once I get scaling for MPX running... Cheers Magnus |