> On 5/5/19 7:23 PM, Tim Wescott wrote: > > My kid saw a need, and filled it. > > > > I don't know if the Linux tablet world needs this, but if it does, he > > and I need help figuring out how to promote it. > > > > Synopsis: ?It's an automatic screen rotator, such as every self- > > respecting phone has. ?James has found a somewhat lame version that's > > written in Python and that only rotates applications on the desktop, > > not the desktop itself. > > > > This is written in two parts: a Rust daemon that calculates the > > orientation of the computer and makes it available in a file, and a > > (quite small) script that interfaces between the daemon and X to > > accomplish the screen rotation. > > > > https://youtu.be/39ocJu-t2bA > > > > https://github.com/rantingpirate/spinnrd > > > > A screenrotater like that would be a feature within the Desktop > environment. Like an option in desktop settings or something like that, > so you would want to hook it into the window manager. > > > There are several linux phone/tablet environments. Currently it all has > to piggyback on android but there are efforts to remove our dependency > on chinese hardware. > > here are some starting links for insight on projects where this feature > would be most useful > > Plasma Mobile - https://www.plasma-mobile.org/ > > Ubuntu Touch - https://ubuntu-touch.io/ > > > See if this is a feature they need help with.? I only mention Ubuntu > Touch for research purposes (I recommend against using any distro that > sells themselves out to MS) however it does give you some idea of the > state of mobile distros, and where to look to add your features. > > > Another option is the RasPi community. This would be a nifty feature on > small ARM boards. Post the github link on an appropriate forum and you > will probably gather interest. I know Plasma already has a mechanism to > rotate the screen but a DE agnostic version is always welcome.
This problem should be solved at the fundemental frame buffer layer, aka DRM2, or what ever fb driver the system is using at boot, solving it at any higher layer is just slow and error prone. The fb layer needs to be taught that horizontal and vertical screen dimensions map into x and y space depending on theta. Then the pixel map function needs to take theta in too, and viola, you can now draw on a screen that is either orientation. Then you have to feed a repaint event to the upper layers and they have to be taught there screen size can change, and then your pretty much done. -- Rod Grimes [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
