Smooth scrolling again

[Simon Thum]

On 11/08/10 22:55, Max Schwarz wrote:
> Hi Simon,
> 
>> That sounds fine. But how are button events being generated which match
>> a potential only-smooth-scrolling input?
> I'm not sure I understand your question. I didn't change the generation of 
> button events in any way. They are just emitted in parallel by the old code.
OK - I got it. I assumed you would be handling "high-precision wheels"
or something like that in evdev, but that's not the case.

Still, the 42 is a bit odd. Towels anyone?

>>> You want that distinction in the server? That would require more changes,
>>> since non-integrating valuators would need to be handled the same as
>>> relative valuators in most contexts.
>>
>> True, though negligible for bit-flag based modes.
> Okay, now we need a decision ;-)
> I'll change it if it's wanted, but it'll blow the patch quite a bit up ;-)
I guess that's mostly Peter's decision, with a twist of spec compliance
related considerations.

>> We have axis labels ( = properties + some shi shi), why not use
>> properties to communicate the axis resolution? It seems that the axis
>> resolution field is well-intentioned, but hasn't actually been used.
> I'm doing that already in one direction (client -> driver) if someone wants to 
> change the evdev wheel resolution. I think the right solution would be to emit 
> a XI event telling the client that the device has changed.
Yes. But AFAIK such an event should have existed since ever but didn't
come to live. Devices in X have been seen as something quite static, and
it's hard to fix that through the stack. And, no-one so far knows that
shiny new event, inducing a considerable take-up delay (servers, libs
and apps need updates).

An input property, though a generic tool, can be listened to right now.
You only need to know its name.

Cheers,

Simon