uinput keyboard handler

[teleshoes]

rudimentary keyboard handling using /dev/uinput
(solves issue #5 for me)

[Tomin1]

Keyboard handling/mapping on VNC seems to be a difficult topic. It would be good if there were some source for best practices on how to implement it. Did you do any reseacrh on how other servers do it or how clients behave wrt. to this?

How did you test this? Which client(s) did you use?

[teleshoes]

It would be good if there were some source for best practices on how to implement it. Did you do any reseacrh on how other servers do it or how clients behave wrt. to this?
How did you test this? Which client(s) did you use?

yes, i looked at several XWindows vnc servers, and at wayvnc. this thing im doing is weird, tho; im using the uinput linux module to send key events. lipstick2vnc is pretty weird itself, tbh.

i tested with xtigervncviewer and xtightvncviewer. i use it constantly to send messages

[Tomin1]

It would be good if there were some source for best practices on how to implement it. Did you do any reseacrh on how other servers do it or how clients behave wrt. to this?
How did you test this? Which client(s) did you use?

yes, i looked at several XWindows vnc servers, and at wayvnc. this thing im doing is weird, tho; im using the uinput linux module to send key events. lipstick2vnc is pretty weird itself, tbh.

That sounds good, seems like you've done your homework. 😉 😄

Yeah, this lipstick2vnc is nothing more than a way to get the compositor content passed over USB for another system to use and as such not a replacement for a real VNC server. There are certainly things that would need to be done to make it proper. E.g. performance is not optimal.

What would be the alternative to uinput (i.e. the not-weird way)? Is it perhaps libevdev or something that libinput provides?

Anyway, I'll test this and let's see if we could merge or if there is something that should be corrected first. I think having something is better than nothing, assuming it doesn't regress what we already have, and that something can be always improved.

[teleshoes]

on a side note, i would prefer to make keyboard support DISABLED by default, but we already had -M | --no-mouse-handler so i matched it with -K | --no-keyboard-handler.

i think i should change it to -k | --keyboard-handler

[Tomin1]

on a side note, i would prefer to make keyboard support DISABLED by default, but we already had -M | --no-mouse-handler so i matched it with -K | --no-keyboard-handler.

i think i should change it to -k | --keyboard-handler

Yeah, that's a good idea. I think it makes sense because this keyboard support is experimental at best.

[Tomin1]

LGTM. Thanks for your contribution!

[teleshoes]

yay! thanks for merging these PRs!