Quote:
Originally Posted by frostschutz
So somehow writing to /sys/class/graphics/fb0/rotate "dirties" it and from then on it starts flipping the rotation around and suddenly you FBIOGET sometimes 1 sometimes 3 and you start drawing things upside down. So on one and same device you get two separate possible behaviours: it might flip the rotation or it might not. Confusing!
|
I don't even want to know the conversations that must have gone on behind the scenes the accept a kernel driver that did this in the first place and make pickel and nickel work around it rather than make a simple driver with highly predictable results.
What a waste of CPU power... reinitializing chips repetitively....because of redundant variables....
Quote:
|
As a result, if you use FBIOPUT_VSCREENINFO, you have to use it twice in order to make sure the rotation is what you intended.
|
That's one solution.
The race conditions are the main problem.
In my own code (not shown), nickel and pickel are actually -SIGSTOPped, and the dummy zforce-ir-touch driver is disconnected by the virtual keyboard emulator; So it's not accumulating buffer data and clogging up.
So thats how I avoid race conditions as much as possible.
When I restore the buffer, I send nickel and hindenburg -SIGCONT.
So I could actually use your "write twice" solution without fear of race conditions with nickel, and I could add pickel to my killall list for extra security.
I probably ought to look up linux signal processing to make sure there's no race conditions possible, but in practice it's not been a problem. Even if it sits idle for a long time, nothing happens until -SIGCONT, and then the system immediately goes to sleep.
So unless it's coincidence, I think other signals / messages might queue up.
But Nickel appears to continue to run stably as far as I can tell. [ Note, the Glo Freezeup is happening when Nickel is running, so don't jump to wrong conclusions. And I have finally got an inkling of an idea of what might have caused it... and it has nothing to do with the code in this thread.
]
I don't see why you couldn't do the same thing, for if you are only writing to the buffer for a brief period of time; Your doing a brief -SIGSTOP is not likely to bother nickel or pickel's activities nearly as much as my long term interruptions do.
Of course, writing to the same screen that nickel is using is risky in it's own right, because there's nothing stopping nickel from reading that data and wanting to use it again -- assuming that the images it wrote there earlier are still valid. Not that I fully understand what you are doing, but it sounds riskier than what I want to do which is a total save, disable nickel and hindenburg, allow another application to run for a while, and then do a total restore and re-enable of nickel and hindenburg.
eg: I'm wanting to do the same as classic job control for a terminal, to allow two or more processes to share a screen.
Each application has it's own rotation, which may be the same or different. I just want to remember it during the save and restore operations, because the screen is not symmetrical and so rotating data already on a screen on the fly is impractical. It would change the drawings scale factor....
Three ideas come to mind from your analysis:
1) Nickel and Pickel already expect the weird behavior, so fixing the driver (assuming the behavior actually is broken) may not be an option as that could break Nickel and Pickel.
2) Pickel reads the buffer twice in a row before writing once; That's normally a useless operation unless the data in some variable changes from one read to the next. So pickel might be detecting a buffer rotation mode by comparing a variable we're not inspecting, and deciding to flip based on that. You might want to do a memcpy, and memcmp from one read to the next, and not read the /sys directory at the same time, to see if any variable changed during double reads. (It could also be stupid code.)
3) The actual "pseudo-random" flipping of the screen appears to be happening during the write operation, and in the write code of the kernel driver; because it's actually modifying the data structure of the write ioctl. So -- that narrows down the portion of the driver code to look at, and hope against hope there are some comments in the source code that make sense out of this unexpected extra rotation activity...