Bug 105592

Regarding 1: I'm not sure what exactly the behaviour should be, could you expand please?


> 2) Add delay between scroll button press/release emulation.

don't we do this? The timestamps of the events should reflect the button press/release times, right?

About #1 - I want for mouse cursor to move when on-button scrolling is in progress. I've done it by simply adding

	/* allow motion events for mouse */
	if (device->tags & EVDEV_TAG_EXTERNAL_MOUSE)
		return false;

to evdev_post_trackpoint_scroll() function, but not sure if that's the best way or if it doesn't break anything. Seems to be working for me without any sideeffects.

For example if cursor is at screen center and mouse is on the middle of mousepad and I start scrolling by dragging down - the cursor stays at center but soon I run out of mousepad. Now I cannot simply move the mouse up, because then cursor will also move up. I have to lift the mouse and place at the center of mousepad. Ideally I should be able to operate without lifting mouse.

With the suggested changes when scrolling down the cursor also would go to the bottom of screen, then I could release the scroll button and move the mouse to the center of mousepad, restoring the original 'state' - cursor at center of the screen and mouse on the middle of mousepad.

About #2, I see, the press event is sent with original timestamp. I will experiment some more and will come back later with results.

That probably was quite confusing explanation about #1, lets try again.

What I mean that currently after I've scrolled down and my mouse is at the bottom of the screen while cursor stays at center, so I cannot access the lower half of screen without having to lift mouse.

Normally (at least for me) the mouse position on the mousepad is directly correlated with the cursor position on screen - if mouse is at upper left corner, cursor is at upper left corner. If mouse is at lower right corner, cursor is at lower right corner. Any operation when mouse is moved while cursor is immobile (or moving at different speed) breaks this correlation and to restore it you must lift the mouse and reposition it (or you will run out of space on desk sooner or later).

Allowing mouse cursor to move (not swallowing movement events) while scrolling would keep this correlation between cursor position on screen and mouse location on mousepad.

Of course this correlation detoriates with time (nothing is perfect), and you will stil have to lift and reposition mouse time from time. But not after every few scrolls (or each scroll when scrolling larger files).

wait, you want to emit *both* scrolling and movement events at the same time when button scrolling? do I understand this right?

Yes, but only for mouse. If that sounds strange - try it and I believe you will understand why it would be better. I don't know if there are any technical implications, but seems to be working for me without any glitches.

I did some experiments with button press/release emulation. Yes, the events are posted with correct timestamps (old, new), but unfortunatelly they don't work in Eclipse project manager. What's worse - in any other places in Eclipse or other applications it appears to be working fine. I tried some variations of timer delays - it was not working with 0 delay, but 50ms was enough. *Sigh*, if it works everywhere except one thing, then obviously libinput is not the right place to get it working.

ok, I'm going to have to say no to this one sorry. Mostly because this is a rather experimental feature and I can see a fair number of things that can go wrong when you interleave scroll and motion events.

Realistically, what should happen is that the compositor (using libinput) gets both events but only forwards the scroll events, using the motion events for cursor motion only. Alas, this cannot work because there is no association between those two events. And not forwarding the motion events would mean the enter/leave status is wrong in the client. That can lead to button clicks going astray. In other words, the only way this would work is sending both events to clients and hoping it works. AFAIK, nothing in the desktop stack is prepared for this right now, so it may work coincidentally but certainly not by design.

Implementing this at such a low level as libinput means we have no per-application control over the behaviour and, worse, need to implement some toggle to allow for this behaviour. That again makes the maintenance effort a lot greater, despite requiring the desktop environments to expose the toggles for it.