Mouse support?

[knghtbrd]

Is it perhaps possible that mouse support might be implemented using Consolation? Either taking some advantage of its codebase or creating whatever bridge might be necessary for it to work. I suggest Consolation rather than GPM because the former has a lot more support for hardware using libinput than GPM does.

If there's any semblance of the necessary support to be found, I'd be interested in helping with the glue. If I'm far off base and mouse support would have to be done from scratch, it's not a project I'd want to take on myself at the moment.

[pataquets]

I'd like to add, Consolation would be great, but better yet if offers accessing the clipboard/selection from scripting.
In the past, I tried to access selection with GPM and failed. Just my 2c.

[knghtbrd]

It might be that easy. Consolation expects to access a VT and this kinda isn't that. Perhaps one, the other, or both could be extended to work together, or maybe much of Consolation's code needs to more or less be embedded into kmscon. If that's the case, it may not be a desirable solution. I haven't looked yet and if someone else has maybe I'm wasting my time even thinking about it or perhaps someone's already working on something. In which case working together might speed up development.

[Aetf]

Likely this will require support first in https://github.com/Aetf/libtsm, which is what kmscon uses internally. I'm not familiar with mouse support in terminals in general, so can't estimation the amount of work needed. But feel free to experiment. I'll try to review if you end up with something and can explain to me :)

[fdupress]

MacSlow implemented some gpm-like mouse support a few months back: kmscon#99 (comment)

Given the work was done on a sibling fork, I don't imagine a rebase will be particularly straightforward, but it might be good to reach out.

[MacSlow]

MacSlow implemented some gpm-like mouse support a few months back: dvdhrm#99 (comment)

Given the work was done on a sibling fork, I don't imagine a rebase will be particularly straightforward, but it might be good to reach out.

I still need to do that... and hopefully will do this in the next few days... since I want to get my stuff in the hands of more people able to easily test mouse/cut/paste support and my gyro-sensor stuff.

In case people wonder what I am talking about... have a look at the "screencasts" here: https://www.youtube.com/playlist?list=PLXvTBWcnTI1OHF7-Op-ASYsQKKg1TYb5Z

Just wanted to jump in and say it's coming and I am not dead ;)

[MacSlow]

Moved/ported the output-rotation support already... see https://github.com/MacSlow/kmscon-aetf/tree/aetf-output-rotation-support.

This is against aetf's develop branch.

Now working on the mouse-selection/cut/paste support... maybe by tomorrow if all things go smooth. After that the gyro-sensor support.

[MacSlow]

Just finished moving/porting over the mouse selection/cut/paste support too. If you want to try it out give https://github.com/MacSlow/kmscon-aetf/tree/aetf-mouse-support a spin. This also includes the output-rotation support, since it's build on top of that branch.

The gyro-sensor support is the last thing I still need to do, but that will have to wait for tomorrow... I am dead tired right now... good night!

[grepsuzette]

Wow amazing! Thank you.
Will try to test the mouse support this week.

[MacSlow]

For what it's worth... Consolation can be found here: https://salsa.debian.org/consolation-team/consolation. So far, as @Aetf mentioned, libtsm does not yet interface with Consolation in any way. Thus there is no clipboard- or scripting-support in the mouse-selection I implemented... if that's what Consolation provides.

That being said, there is nothing stopping libtsm to be extended with probing-support of a running Consolation-daemon and using that if found or if not found falling back to my current implementation.

I am just looking into the codebase of Consolation to see/guess what amount of work it might be.