Hacking Pressure Support Into Xf86-Input-Tslib

[chris_c]

While I haven't quite got to grips with the best way to report a 3rd axis to xorg
(seriously wheres the api docs for xf86PostMotionEvent and friends - this is really holding me up!)

I'll soon have it cracked, hopefully!

I believe now that most of the input problems are NOT with tslib but rather with xf86-input-tslib, specifically with the "interesting" state machine it attempts to maintain to emulate more than one button.

I don't know how easy it is to detect the shift key being down inside a driver - but I'm tempted to do right click as a shift click
or maybe it might be possible to do low pressure as left click and high pressure as right click

I'd welcome peoples thoughts on this....!

The input coming from tslib seems quite raw, and it should probably stay that way, xf86-input-pandora-touch should probably get all its information from the evdev interface /dev/input/event? and be responsible for averaging things out....

Again I'd welcome input here!

 

[EvilDragon]

That sounds good, as the current input driver is just a hackup that works... but can be done way better.

I like the Shift-Right-Click idea... maybe even make that configurable to that the user can decide the key to use?

One thing I'd love to try out would be to use pressure sensitivity for right click... i.e.: Normal click = Left click, Click with more force = right click (deadzones need to be configured).
This MIGHT work well, depending on how different the force is you have to use here.

What do you think?

 

[sebt3]

hi chris_c,

Let me be the first to say : awesomeness coming

cheers,
seb

 

[notaz]

The input coming from tslib seems quite raw, and it should probably stay that way, xf86-input-pandora-touch should probably get all its information from the evdev interface /dev/input/event? and be responsible for averaging things out....

If you do that, use /etc/pointercal for global calibration settings (see tslib source on how to interpret those values). Alternatively you can use both tslib and evdev using pointer position/pressure from tslib and shift key from evdev. You can wait for events from both with select() with no need to waste resources on polling or extra thread.

No idea how to pass this to X though, I hope it's possible at all.

 

[chris_c]

Its entirely all possible - initially I'm hacking tslib-input-dev pressure support but probably won't release this as I'd rather tslib just went away...

 

[whynodd]

I believe now that most of the input problems are NOT with tslib but rather with xf86-input-tslib, specifically with the "interesting" state machine it attempts to maintain to emulate more than one button.

I don't know how easy it is to detect the shift key being down inside a driver - but I'm tempted to do right click as a shift click
or maybe it might be possible to do low pressure as left click and high pressure as right click

low pressure as left click and high pressure as right click: Not good idea. How would you avoid a leftclick just before a rightclick while the pressure level rises? How to deal with spikes?
Shift+Tap or FN+Tap to rightclick should work way better and is more user predictable. Its the Mac-style.

Think much simpler: Left click as long as you touch the screen and the simulated click is released when the finger is released. No weird state machines, no rightclick-guessing. I didn't even use the borked rightclick because it never really worked, was triggered accidently instead of a drag or it fighted against a leftclick at the same time (context menues suddenly closing).

edit: btw, thank you for looking into those input issues.

whynodd

 

[chris_c]

with most gui's a "click" never occurs till a button is released you can hold a button down all day long with most tool kits, you can even move away from a button then release the mouse without them activating...

So I'd only post a button event when the stylus is removed from the screen - based on its maximum pressure, I could then say right or left click - but its still and experimental idea....


While with my current progress I'm reporting 3 axes to X - the third pressure axis is unusable until I can convince X that the driver is an extended input driver.

Thing is I've looked at three different driver's source - all of which are used as extended input drivers - and even looked at HAL rules and X configs to see if I can spot what make a driver an extended input driver.... At the moment I think I'm doing the same as the other drivers I even register a dummy XI property just to be sure.

Once I've overcome this hurdle its basically plain sailing - I just feel like I'm battering my head against a wall at the moment....!

 

[whynodd]

with most gui's a "click" never occurs till a button is released you can hold a button down all day long with most tool kits, you can even move away from a button then release the mouse without them activating...

So I'd only post a button event when the stylus is removed from the screen - based on its maximum pressure, I could then say right or left click - but its still and experimental idea....

You are right. Events occur in this order:

With Mouse:  LeftMouseButtonDown -> [several MouseMove's eventually] -> LeftMouseButtonUp -> MouseClicked at last position
Touchscreen: FingerDown          -> [Finger moves around while down] -> FingerUp          -> TouchscreenClicked at last position

I still don't think its a good idea to decide at the end of this example if it should be a right click or not because it HAS to start with a LeftMouseButtonDown, otherwise you could never drag and drop something.
Imagine you want to paint some heavy dots (not strokes) with high pressure in a drawing application and some *magic* decides for a right click (after you painted a dot and lift the stylus) and opens a context menu.. Not very intuitive.

The event order described in the code box above is what should happen. But it doesn't happen on the Pandora in the right order or it doesn't send all necessary events. Or the borked right click / doubleclick mechanics interfere. Also, TS-Input is sluggy (loses something somewhere) while nubmousing is very fluid. Its nearly impossible to take handwritten notes because of this. However, there is really something wrong as it is now. Moving icons on desktop, maximizing windows.. Usability suffers..
I don't know how to write drivers, so ideas and feedback is all I can give .

 

[chris_c]

Yeah i'd not thought about the touch screen being used for what its most useful for ie drawing!

the different pressures for different clicks idea is out! lol

I think its tslib that causes the lag, and I know that mouse event do lag in the X event queue...
however with tslib removed from the equation then its one less layer! so hopefully it should be just that bit more responsive!

Now if only I could figure out how to convince X this new driver is an extended input driver.....

 

[chris_c]

using a tool call xidump I have verified that I am reporting pressure values to X

I'm just using pressure values from tslib which is giving some odd readings but as soon as I can get the driver recognised as an extended input device I'll be ripping out all the tslib stuff

however, as gimp etc are not going to use the pressure info until they see an extended input driver
I have to say I'm a little stumped it could be any number of things in the chain including the fact that sometimes gimp wont recognise other devices as extended devices....

 

[chris_c]

OK turns out my pressure hack was working almost straight away - xorg *is* recognising it as an extended driver and from a few different posts v 2.8.6 of gimp may have a bug with recognising extended drivers....

I need to get debian going as believe it not it has a more upto date version of gimp than angstrom!

Once I get chance to verify that the problem is with that version of gimp - I'll start working on a proper version of a none TSLIB xorg driver that reports pressure

What with file conflicts in packages - missing or incorrect symlinks for lib's - and really elderly packages in Angstrom, I can't wait till the wrinkles are sorted out with Debian on the Pandora....

 

[chris_c]

turns out it is gimp 2.8.6 with the problem (nearly 1.5 year old version still in angstrom repo?) I tried out 2.8.10 in debian and what do you know a whole bunch of extended input drivers, hours wasted because angstrom is so badly out of date.... ARRRGH

I have an extra axis but still need to work on the values range. Having said that gimp should be looking at the range values from xinput - xidump does!

Also with Debian X chewing the cpu at the moment its hard work in gimp!

So... good news - its more than possible to report pressure events to X, my nasty hack of xf86-input-tslib does that already.
bad news - its not going to be any time soon - I have to get a more upto date version of gimp going.... oh joy

 

[sebt3]

why not using something lighter that does also support pressure sensitivity. hint pencil does

 

[chris_c]

That's a good idea! I'd forgotten about pencil! - I'll look in a week or two when I'm less busy and my Pandora come back from Holiday - gone to stay with some relatives in Newcastle for a short break...

 

[notaz]

Great work, looking forward to xf86-input-pandora-touch to materialize!

 

[Esn]

I'm not entirely sure what this is about...

But I think I should mention that currently, I very frequently use shift-click to move around the windows of programs that are too big for the Pandora's screen.

Pencil, for example, would be unusable without that. Also, even some of the config screens in xfce have to be moved around this way...

If what you're doing will stop me being able to use shift-click for that, then I'm against it...

 

[chris_c]

so sorry you're against pressure support, I won't implement it then when my Pandora comes back, neither will I suggest that you consider using the traditional alt-drag to move windows around....

 

[Esn]

so sorry you're against pressure support, I won't implement it then when my Pandora comes back, neither will I suggest that you consider using the traditional alt-drag to move windows around....

I think you were detecting a hostile tone in my tone when none was intended.

Alt-drag is simply not nearly as comfortable, since alt is in the middle of the keyboard, right under the screen. For using Pencil, alt-drag would significantly decrease the program's usability. Simple as that, no hostilities or insults intended...

If there was an option for custom keymappings on the Pandora, as discussed here, this wouldn't be an issue; everyone could make settings for whatever was comfortable for them...

(also, as I said, I didn't and don't really understand what this thread is about... too much technical terminology in here for me... is this about changing things in every program, or just in Pencil?)

EDIT: The new Grafx2 version seems to have an interesting approach to L/R clicks "Allows swaping left-click for right-click with modifier key (select/ctrl by default)."

 

[chris_c]

no the hostile tone was all mine

you wade in on a thread not understanding what its about - and then insult my intelligence by assuming I would force a fixed config on the end user. Thanks

 

[Esn]

no the hostile tone was all mine

you wade in on a thread not understanding what its about - and then insult my intelligence by assuming I would force a fixed config on the end user. Thanks

I said if.

...and fixed configs for the end user on the Pandora are not exactly unprecedented (as far as I know, only the nub mappings can currently be modified a little; the other buttons cannot), so if it is indeed user-configurable that would be very welcome...