Disables the button click generation (EvdevWheelEmuInertia) and
generates scroll valuator events directly.
Signed-off-by: Max Schwarz max.schw...@online.de
---
I tried to support turning wheel emulation on/off at runtime.
This involves calling InitValuatorClassDeviceStruct() again
to add the new
EvdevBitIsSet(array, KEY_A):array[0] (1 30)
BitIsOn(ptr, KEY_A):((BYTE*)ptr)[3] (1 6)
That is true on little-endian. Big-endian machines have that byte in position
0, so that one would need to be ((BYTE*)ptr)[0] (1 6).
Another simpler example:
long a = 0x04030201;
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
src/evdev.c | 76
Have you looked into switching the evdev bit arrays from longs to bytes
so we can standardize on one type of bit array?
That would be possible. Longs are used because the linux evdev layer uses
longs and we can let ioctl() write directly into our bitmask arrays. I can
change the occurences of
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
sorry, forgot to actually make EvdevBitIsSet/EvdevSetBit inline
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
make that static inline -.-
src/evdev.c | 76
Why not have EvdevBitIsSet and EvdevSetBit use BitIsSet/SetBit with
endianness-fu?
What would you gain from that? I think my implementation is simple and
straight, endianness-fu isn't going to make it nicer...
Max
___
xorg-devel@lists.x.org: X.Org
Hi Peter,
you could make the support compiled in, but not compiled _out_. so even if
you HAVE_SMOOTH_SCROLLING, the old bits are ready to go when enabled.
if no smooth scrolling axis is otherwise present on the device, just post
button events as previously.
Well, the proper thing to do would
a REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Resend, my E-Mail client ate the patch...
src/emuWheel.c | 19 ++-
src/evdev.c| 34 +++---
src/evdev.h|4 +++-
3 files changed, 48 insertions(+), 9
This bug led to inverted scrolling axes with legacy drivers that
do not support smooth scrolling classes.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Applies on Peter's next branch.
dix/getevents.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/dix
Hi Peter,
Input: Add smooth-scrolling support to GetPointerEvents
There's a subtle bug on that one: Old-style scroll button presses create
inverted emulated presses (and maybe inverted valuator events, but I don't
know which direction is 'up' or 'down' on the valuator).
Take a look at
a REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Hi Peter,
here's a tentative patch for evdev for smooth wheel emulation. It applies on
your smooth-scrolling branch.
Note: Without this patch (i.e. using the old button interface) wheel emulation
direction
Hi Peter,
Am Monday, 26. September 2011, 16:11:05 schrieb Peter Hutterer:
sorry, I completely forgot about that.
No problem at all. Your approach is certainly more flexible than mine ever was.
I like the idea of doing both-way emulation in the server, that removes the
need to create both type
(1UL 32) evaluates to 0 (at least here), so do the
fraction calculation in two steps as in libXi. Fractions on xXIRawEvent
were not multiplied at all, which also gave 0 as result.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Hi,
I noticed a problem (see patch) with Daniel Stone's patch
woha, I didn't notice someone else stepped up and did it even better
(XIScrollClass co by Peter). I'll look into that now, sorry for the noise.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info:
On Wednesday 17 November 2010 at 23:55:20, Simon Thum wrote:
if possible, wrap it. it's much easier to work around issues than when
each driver just mangles the struct directly. But I don't think you need
a new call here, just re-using the existing InitValuatorAxisStruct
should do.
Hi Simon,
The clients depend on XIDeviceChangedEvents anyway to acquire the new
resolution when the user switches input devices (see pscrolltest.c).
Though that sounds fine, I think the event is intended for master/slave
issues. That's deep in spec land, however. Read up and see if it
Hi Simon,
Still, the 42 is a bit odd.
Caught me ;-)
The value was a lucky guess, but it works pretty well for me (I'm using a
TrackPoint to test it, other devices might yield other values...)
Towels anyone?
No Bugblatter Beast in sight, so I'm safe for now ;-)
I guess that's mostly Peter's
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.
You want that
Hi,
I finally found some time for smooth scrolling.
I've got rebased patches against git versions for
xserver, xf86-input-evdev, xf86-input-synaptics
in my github repo at https://github.com/x-quadraht/pscroll.
Would you mind checking them and telling me what needs to be done to get them
merged?
Hi Simon,
A thing I'm
missing is how you're establishing the relationship of smooth and button
scrolling? It might just be me since I'm only looking at the diffs.
It's certainly subtle ;-)
Look at EvdevProcessRelativeMotionEvent().
In case of a change on REL_(H)WHEEL the clicks are queued and
Hi Daniel,
Nice!
Thanks ;-)
I think the NoIntegration stuff is entirely unnecessary though -
if you've set your axis range appropriately, then you won't need this
hack at all. If you can come up with a patchset that doesn't require
this, I'd be more than happy to test it with Synaptics.
Hi Simon,
You'll have to rebase them against git master to get into mainline. Why
didn't you use git master to start with?
That's because I like to work with the versions I have installed. Otherwise I
would need to compile the whole Xorg stack, this way I can just change one
component at a
Hi,
results!
I'm finally content with how the code looks and feels :-)
Comparison:
before: http://c-palb.de/~max/before.ogg
after: http://c-palb.de/~max/after.ogg
The videos don't do the change justice, it feels _much_ more natural.
I had to patch the respective input drivers, the server
Hi,
I got my simple testbench to work now:
xorg-input-evdev sends high resolution scroll information generated by the
wheel emulation code into the server, and my client app (pscrolltest) receives
it along with resolution information.
I will start implementing the feature in toolkits and if
not really, all valuators sent to the clients are always absolute (with the
exception of the ones in RawEvents). so even though the driver posts events
as relative, they're just added to the current value and sent as absolute
anyway.
What's the point of relative valuators on the driver-side
Hi all,
here is an update on my progress:
I have wheel valuator events generated and captured by
a small test program (pscrolltest, see my repository on github:
http://github.com/x-quadraht/pscroll).
The proper valuator resolution is reported (1 unit per old-style scroll click
per default, as
On Wed, 2010-04-07 at 12:58:11, Simon Thum wrote:
I'm unsure I get it. I assumed you were breaking up the 1:1 relation
between scroll button presses and your scroll valuator, such that the
valuator may work with much higher precision while button-scroll remains
working for apps unaware of the
Am Mittwoch 07 April 2010 16:13:09 schrieben Sie:
First, you could have one factor which governs how many valuator scroll
steps are needed to trigger one button scroll event, as discussed above.
This would need to be enforced by the driver. If a mouse is clicky, it
may be 1 or the driver would
Hi Simon,
The problem I see is that it's really degrees or cycles on a wheel, or
some distance on more freaky devices (e.g. pad on mouse). Maybe it's
preferable to add some (user-overrideable) axis information which
toolkits may use to ultimately do something sensible.
Well the way it is now
xf86PostMotionEvent or create a new
xf86PostScrollEvent?
2) I really would like to extend the keyButtonPointer xEvent in Xproto.h to
report the relative scrolling motions, but would that break compability?
Should I use GenericEvent?
Thank you,
Max Schwarz
This would break compability. Old software just expecting a few button ticks
would suddenly scroll wildly.
2) Provide additional axis events with true resolution
I realize that the GUI frameworks would also need work to make them use the
new interface.
Thank you,
Max Schwarz
32 matches
Mail list logo
