View Single Post
Old 12-08-2019, 04:13 AM   #708
rtiangha
Evangelist
rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.
 
Posts: 495
Karma: 356531
Join Date: Jul 2016
Location: 'burta, Canada
Device: Kobo Glo HD
Quote:
Originally Posted by NiLuJe View Post
Bonus points if you fix KSM to actually use the proper current fb orientations on (at least) Mk. 7 devices, because that's currently not the case .
OK, I don't have a Mark 7 device so I don't know what the issue is or what expected behavior is, but I'm guessing there's a rotation switch that gets toggled and stores the value somewhere? So it'd be a matter of getting KSM to either read this value and respect it, and/or set it itself and hope that when nickel (or whatever; koreader or plato) loads, it respects that value?

Do we know where this value or state is set or stored? And do Kobos run X? Or is it all virtual framebuffers? If it's virtual framebuffers, can something like fbcon and looking at what's in /sys/class/graphics/fbcon/ help? Can you pass kernel arguments through uboot? Or is the issue that the display orientation doesn't match the touchscreen orientation (and/or the orientation the application expects)?

I dunno, I'm just throwing ideas out there; still just looking around and absorbing; enjoying your code comments, btw. :P

Last edited by rtiangha; 12-08-2019 at 05:05 AM.
rtiangha is offline   Reply With Quote