search

llandsmeer / inkvt

Experimental VT100 terminal emulator for Kobo e-readers
GNU General Public License v3.0
39 stars 5 forks source link

[RFC] Minor FBInk tweaks #1

Closed NiLuJe closed 4 years ago

NiLuJe commented 4 years ago

I kinda got sucked in by the "hey, something that works 1:1 with the col/row setup" effect, so, err, here we go ;p.

This tweaks FBInk usage a bit, mainly to:

In practice, the refresh are mostly coalesced properly by the kernel, there's just a bit of overhead involved in that, as well as in FBInk's insane internal positioning tweaks to handle a grid layout ;).

Also, I started from f67ea89 because master didn't quite work out on my end, I could only get a few apparently random input events to make it across evdev2serial? Fair warning: I have a crapload of input devices on my desktop, keyboard is AZERTY, if that makes any difference, and I tried this on a H2O, where g_serial might not be behaving exactly the same (module was built from the actual H2O sources)?

And I have zero serial stuff built in my kernel, so I only have a /dev/ttyACM0 on my end:

 [Feb24 18:03] usb 1-9: new high-speed USB device number 5 using xhci_hcd
 [  +0.022047] cdc_acm 1-9:2.0: ttyACM0: USB ACM device
NiLuJe commented 4 years ago

I'm fairly terrible at C++, so, do take this with a grain of salt ^^.

NiLuJe commented 4 years ago

(This may have prompted me to update some bits of FBInk API documentation, as well as fill some feature gaps with new API calls, so, win-win ^^).

llandsmeer commented 4 years ago

Woah thanks so much, that some really really nice improvements! Now I'll have to try figure out how to apply a pull request :smile: I'll try to merge it today!

Fix color handling (spoiler: stuff is now printed white on black, which may or may not actually be on purpose :D).

I prefer black on white, but I'll just invert colors somewhere then :) Actual working colors is much better than what I had.

Optimize large term_damage rects refreshes (even though it turns out a lot of stuff does a bunch of 1x1 damage rects anyway :/). Don't go through printf formatting when it's unneeded. I was originally thinking that it'd be neat to draw row by row instead of cell by cell, but after seeing how term_damage actually gets called, this might be more complex that I expected ^^. In practice, the refresh are mostly coalesced properly by the kernel, there's just a bit of overhead involved in that, as well as in FBInk's insane internal positioning tweaks to handle a grid layout ;).

Yes, thanks a lot! There was some very noticeable lag on large outputs.

Also random quick'n dirty Makefile mangling to make it build on my end, which you probably don't actually want ^^.

No problem

Don't worry about C++, my experience doesn't go much further than a C-with-classes style programming. Because if I write just plain C it will end up as a gigantic mess :open_mouth:

So if I understand correctly, you have a custom kernel without g_serial.ko and friends? I started from a clean kobo-update-4.19.14123 firmware 7, and I tried to make this project work on an unmodified libra h2o (except for kfmon+koreader). My laptop also runs a plain unmodified ubuntu. Maybe I can just package those loadable kernel modules within inkvt?

Yes sorry about the evdev over usb thing.. that makes it work perfectly on my setup (including shift and ctrl modifiers etc.) but probably breaks on anything thats not qwerty.. But if the serial over USB is working I'll happily add a program to send raw pty input to the device using ncurses. Thinking about it, that would have been a much simpler solution to start with... haha

Another possibility is that your serial device interprets binary data as control characters, and breaks when it encounters something outside the printable range. I thought that was solved with setup_serial() but maybe not?

NiLuJe commented 4 years ago

So if I understand correctly, you have a custom kernel without g_serial.ko and friends? I started from a clean kobo-update-4.19.14123 firmware 7, and I tried to make this project work on an unmodified libra h2o (except for kfmon+koreader). My laptop also runs a plain unmodified ubuntu. Maybe I can just package those loadable kernel modules within inkvt?

No, it's the stock kernel, it just turns out earlier devices shipped without g_serial :/. I don't have a Mk. 6, but I fear it may only have been introduced on Mk. 7, with the kernel update involved there. I certainly do have it on my Forma ;). I have no idea how portable those modules could be. I think my H2O build could work across the full Mk. 5 range, but I don't have any other device to test that theory ^^.

llandsmeer commented 4 years ago

No, it's the stock kernel, it just turns out earlier devices shipped without g_serial :/. I don't have a Mk. 6, but I fear it may only have been introduced on Mk. 7, with the kernel update involved there. I certainly do have it on my Forma ;). I have no idea how portable those modules could be. I think my H2O build could work across the full Mk. 5 range, but I don't have any other device to test that theory ^^.

Well.. that sucks.. :/ I don't think there is a easy alternative then, except for a software keyboard. Reading about forcefully loading version-mismatched kernel modules, seems like that would most likely end in flames. Another option is using a ESP8266 as wifi host and sending hardware keyboard signals over the network, but that's a huge waste of battery life I think.

llandsmeer commented 4 years ago

Oh I can use my android phone as both wifi host and a HTTP server and connect a OTG keyboard. That's a much simpler solution than building a low power host usb hardware keyboard from scratch :)

NiLuJe commented 4 years ago

Note that if it comes to that, building the g_serial module is trivial ;).

On Thu, Feb 27, 2020, 14:36 Lennart Landsmeer notifications@github.com wrote:

Oh I can use my android phone as both wifi host and a HTTP server and connect a OTG keyboard. That's a much simpler solution than building a low power host usb hardware keyboard from scratch :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/llandsmeer/inkvt/pull/1?email_source=notifications&email_token=AAA3KZULM3JHJB6ARNC4HZLRE66VTA5CNFSM4K2P6SEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENEM5QI#issuecomment-591974081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3KZSMJKIN3PUMSAEQYKTRE66VTANCNFSM4K2P6SEA .