Disables the button click generation (EvdevWheelEmuInertia) and
generates scroll valuator events directly.
Signed-off-by: Max Schwarz
---
I tried to support turning wheel emulation on/off at runtime.
This involves calling InitValuatorClassDeviceStruct() again
to add the new valuators or remove
n button events
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 interf
using 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 Sc
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
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 t
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 wo
Am Donnerstag 08 April 2010 01:42:00 schrieben Sie:
> for evdev, just applying some velocity calculation and adjusting the number
> of clicks accordingly may be helpful already. Right now, if you scroll 1,
> 1, 1, 1 that looks the same to the client as if you scroll 2, 2. Arguably,
> the latter one
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 an
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,
> 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 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
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
Hi,
I implemented most of the dynamic-resolution feature today.
Patches are at https://github.com/x-quadraht/pscroll/tree/master/patches/ .
The wheel resolution property now resides in the emuWheel.c code, which
reflects that it only affects wheel emulation. I added a manpage entry, too.
Curren
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,
after a nearly year-long absence during my graduation from high school & other
stuff, I came around to update pscroll again.
For those of you who have never heard of it, take a look at my github page:
https://github.com/x-quadraht/pscroll
I have updated the patches to xorg master now. The no
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: ht
(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
---
Hi,
I noticed a problem (see patch) with Daniel Stone's patch
[PATCH 2
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 o
REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz
---
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 is flipped, be
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 d
REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz
---
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 deletions(-)
diff
This bug led to inverted scrolling axes with legacy drivers that
do not support smooth scrolling classes.
Signed-off-by: Max Schwarz
---
Applies on Peter's next branch.
dix/getevents.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/dix/getevents.c
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 wou
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
---
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
---
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
---
make that "static inline"
> 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
> 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 = 0x04030
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 "no
> 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,
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 nee
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 i
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 t
35 matches
Mail list logo
