Multiple keyboard backends + fallback backend for xkbcommon #9
Conversation
This defines the API the keyboard backends will need to implement. It is based on what's in input_xkb.h but cleaned up and simplified. Signed-off-by: Ran Benita <ran234@gmail.com>
This commit ports the XKB handling to the new kbd interface, and makes the input subsystem use it without any direct knowledge of XKB. Some code is moved around but there are no functional changes. Signed-off-by: Ran Benita <ran234@gmail.com>
Currently it's required by xkbcommon. However, we will need it for other backends as well, even with xkbcommon support disabled. xproto consisted only of static header files. We use the XK_ keysym definitions. It is therefore only required during compilation and we shouldn't needlessly duplicate it ourselves. Signed-off-by: Ran Benita <ran234@gmail.com>
This commit adds a very simple keyboard backend which does basic keycode interpretation. It is used as a fallback when xkbcommon is unavailable or is not required. See the file header for what is supported. Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
I really like the cleanup and making xkbcommon a backend. However, why would someone want the "dumb" backend? Its really dumb and doesn't even make much sense for testing. Also, xkbcommon has almost no dependencies except xproto. I will look over it the next week and then merge the stuff. |
|
I have merged the cleanup (I got one less trivial conflict but I think I got it right). However, I haven't merged the dumb-backend, yet. I currently see no reason for this and skipping it will save us time maintaining it. Thanks |
|
Great, thanks. About the merge: seems this commit got lost: e0a1902 it'd be nice to have it back - it makes some annoying debug messages appear for me :) About the dumb backend: I just couldn't do the cleanup without something to show for it :) I guess it can be useful for doing valgrind and as a fallback for when xkbcommon is not there (given that it hasn't been released in any way yet and is somewhat clunky). So I'll keep it alive for random cherry picking, but again I don't mind it much. |
|
I have pulled the dumb-backend. Your arguments seem valid ;) Also I'd prefer discussing the ideas first. I don't want to write the VTE code twice because we did some mistake in the beginning. Also, does the new GLES2 backend work for you? What about the freetype2 drawing? I tested it on my machines and all seems to work fine but I'd be glad to get some feedback. Cheers |
|
Hi, I see you pretty much covered all of the TODOs. What's left there I see is:
|
|
The VTE itself should be pretty easy, I think. I have a skeleton ready - basically a bunch of switch statements which gcc can optimize into tables if it wants - which I think is straightforward enough to be merged. This also applies to the keypress handling. These should make a nice inline TODO list, so I'll prepare a pull request for them. The "harder" part is to get the console buffer handling just right and fast. There are complications like scroll regions and origin mode, and probably others, which are better to keep in mind from the start. I only tried some simple stuff here without changing anything that's already in place. |
|
Oh and I tried the new font and GLES2 backends. I was hit by a couple mesa bugs but after that it seems much better than what was before. The rendering is as fast as I care for and there are no weird kernel messages sent to the console :) I don't really know much about opengl but it seems pretty impressive. I do have one question so I'll open an issue for that. |
Nice. If you think we can postpone some stuff, please add it to the new TODO list in the wiki.
Yeah, I tried to resolve the TODOs myself. TERM=linux seems fine for now. I intend to emulate the linux-terminal for version 0.1. In future version we can try to emulate more complex VTs like vt100/vt220 etc.
What kind of mesa bugs? If they are serious, just tell me, I can report them upstream or try working around them. The rendering is pretty slow on my Intel-Atom so I think I will try some cairo drawing backend to avoid rendering on the GPU. However, good to hear that it works smoothly on your pc. Please see the TODO in the github-wiki. I tried to put up some kind of roadmap. I want to get the VTE subsystem running so we have a working terminal for the 0.1 release. The 0.2 release should be a major cleanup and speed improvements. Cheers |
|
Compiling from git fixed the first mesa bug, than I was hit by this: |
|
Awesome. And yes, those libgbm, libEGL, xkbcommon libraries still have several bugs when used with libdrm but the wayland project is working on getting them resolved. Good for us. Btw. I pulled your fixes. Thanks! The last one solved the performance problems on my machine. Obviously we did render the screen way to often, funny I didn't notice that. I need to find a better way to handle redraws, anyway, we shouldn't redraw it at every change but rather limit it to 50 frames or so. Next two weeks I have a lot of other stuff to do but after that I will have lots of time to work on kmscon. |
Hi,
After reading your comments I thought this will be pretty easy to do and should alleviate some of your concerns.
It basically encapsulates input_xkb.{c,h} into a couple kmscon_* objects, and also adds a second fallback backend to show out it would work.