search

dvdhrm / kmscon

Linux KMS/DRM based virtual Console Emulator
http://www.freedesktop.org/wiki/Software/kmscon
Other
433 stars 81 forks source link

Multiple keyboard backends + fallback backend for xkbcommon #9

Closed bluetech closed 12 years ago

bluetech commented 12 years ago

Hi, After reading your comments I thought this will be pretty easy to do and should alleviate some of your concerns.

It basically encapsulates inputxkb.{c,h} into a couple kmscon* objects, and also adds a second fallback backend to show out it would work.

dvdhrm commented 12 years ago

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. Thanks David

dvdhrm commented 12 years ago

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 David

bluetech commented 12 years ago

Great, thanks.

About the merge: seems this commit got lost: e0a190261686bda00175b9516de371c38c6f4e91 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.

dvdhrm commented 12 years ago

I have pulled the dumb-backend. Your arguments seem valid ;) Before I will start working on your vte-changes I want to resolve all the current TODOs actually. Do you mind adding all the stuff you have in mind to TODO? I have seen several TODO-comments in the recent patches from you and I want to have a clean core before starting on the VTE.

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 David

bluetech commented 12 years ago

Hi, Thanks for pulling. I'm trying to do some work on the xkbcommon side but it's not easy :)

I see you pretty much covered all of the TODOs. What's left there I see is:

bluetech commented 12 years ago

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.

bluetech commented 12 years ago

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.

dvdhrm commented 12 years ago

Hi, Thanks for pulling. I'm trying to do some work on the xkbcommon side but it's not easy :)

Nice. If you think we can postpone some stuff, please add it to the new TODO list in the wiki.

I see you pretty much covered all of the TODOs. What's left there I see is:

  • Which TERM envvar to set. I think linux is fine?
  • What to exec. I think SHELL is fine for now, and we could revise that later.
  • All of the utmp/wtmp logging stuff. I don't know much about that, but I think that's also for later, it'd be too annoying now.

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. SHELL and utmp/wtmp was added to the TODO as an entry: "Copy agetty functionality". We can postpone this.

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.

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. All later releases (0.3, 0.4 or whatever) are grouped together under version 1.0 in the TODO list. Please add all kind of stuff that you have in mind to the list.

Cheers David

bluetech commented 12 years ago

Compiling from git fixed the first mesa bug, than I was hit by this: https://bugs.freedesktop.org/show_bug.cgi?id=44919 But it's fixed now.

dvdhrm commented 12 years ago

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. Regards David