Johnny Stenback (jst@reimari.uwasa.fi) said:
>> Successive motion events should be clustered whenever possible: an
>> application reading the pointing device wants the `current' information,
> This is not always true, if one uses a drawing app (ala Photoshop)
> then the device movement history is VERY important, [...]
That's true. However, clustering only happens if data isn't read from
the device: if X doesn't track the cursor the user is lost anyways:
easing X by returning a single packet is much better than feeding
everything to it. Sure after the cursor is drawn the application must
retrieve all the movements the user has seen. But this means that X
shouldn't cluster events, the device should.
> This could of course be made a boot/compile time option but it should
> IMO be possible to get the movement history...
*If* kmouse gets through, the issue can be considered if there's
the need.
David Miller (davem@caipfs.rutgers.edu) suggested:
> What you describe sounds a lot like the VUID event mechanims Sun OS's
> use for the X server.
And the event mechanism of GGI. Yes, I have to look in them.
Janos Farkas (chexum@bankinf.banki.hu) outlined:
> Wow, 16 dimensions should be enough.. [Would say you-know-what Gates :)]
> But probably any "dial" or "gauge" on such a control device, which
> produces an analogue-like signal is possibly counts as a "dimension"; and
> in this case 16 may be a bit few. I.e. a joystick with two (ehrm..)
> directions, and three other gauges is already five.. Maybe with some
> extra controls, like a "joystick" (more like a cockpit?) usable for
> simulators, I hope you see what I mean.. :)
> Similar for buttons, I can well imagine remote controls used for this
> purpose, and 16 is too few for at least the european mind with a Hi-Fi
> receiver.. :) [With surround control, volume, etc...]
Right. I thought about it, and then forgot. I'll add a flag to
the "flags" field to tell more dimensions/buttons are coming. Thus
one can use multiple packets to describe a single event, if
the poiner requires it. The packet is still limited to 16/16 because
the "flags" field has a finite number of bits.
> And, almost lastly, the 16 bit precision could be too few for some
> purposes.. Let's count: assuming the normal precision is about 150-300
> dpi, bump it up for future devices for 1000 dpi; let's examine a user who
> moves a cursor with 2 feet/seconds around (angry, or so what.. :),
> [...]
The field is 32 bits, I planned to use 16 bits for absolute devices
(-1 is out-of-screen 0 left-est, 65535 right-est, 1<<16 is
out-of-screen) but there's actually no reason for it: 16 is not a
magic number in a 32-bits value. I'll turn to 30 bits of precision,
and there's still place for out-of-screen.
> And probably lastly:
>
>> The basic packet is the following:
>>
>> typedef struct Kmouse_Packet {
>> __u8 magic[2]; /* two bytes to identify the packet head */
>
>> Data transfer is only accomplished in multiples of 4 bytes, and the
>> device returns data in native-endian mode.
> That endianity thing seems ok with me, with one exception; it's probably
> more wise to have the "magic" in the native endian order too
Smart. I'll do it.
Your suggestions will be part of the 0.47 release.
Best Regards
/alessandro
--
__ o La forza dei forti sta nel traversare le traversie con occhio sereno
_`\<, (Paperino)
__( )/( )__ alessandro.rubini@linux.it +39-382-529554