In order to simulate the display of the "One Laptop per Child" laptop, Xephyr needs a "color swizzling" mode. To match the actual hardware as well as possible, this mode only keeps the red component of the signal for the first pixel, the green one for the second pixel, etc. Moreover, it performs a very simple antialiasing (only taking into account the four nearest neighbors). See the attached patch, against Xephyr 6.6.1.
Created attachment 6499 [details] [review] Patch implementing swizzle + simple antialiasing Before integrating this code into Xephyr, you might want to change two things: 1) Enable/disable swizzling with an option (right now, just a "swizzle" variable). 2) When the depth is not 16 (which is best for emulating the OLPC), maybe do something else than just spit out an error message. Just switch to 16bit depth? I was not sure how to do this. Comments/suggestions/bug reports/insults welcome ;-)
Some thoughts from a quick look; - How about some comments in the code, explaining why it is doing what is it in terms of emulating a display. - I think the code could be simpler, more compact and self contained. - You shouldn't need to use the extra shm image, just a chunk of memory like fbdata. That should make the code simpler. - How about a switch to enable the swizzle mode ?
Created attachment 6500 [details] [review] (Shorter) Patch implementing swizzle + simple antialiasing Shorter and a bit simpler version of the same patch.
Created attachment 6548 [details] [review] Patch for swizzle mode with a new postprocessing algorithm
Created attachment 6597 [details] [review] Patch for color swizzling mode (-swizzle option)
BTW I did ask David Turner about licensing this code with the MIT license, he said no problem.
(In reply to comment #6) > BTW I did ask David Turner about licensing this code with the MIT license, he > said no problem. Cool. The patch looks good. Id like to make a few small tweaks to what it does in hostx.c ( move more of it into the seperate source file if pos). Can you just hang on in there till I get a bit of free time to do this ? You have the ubuntu packages anyway people can use right ?
Sure, no problem. Tweak everything you like as you see fit :) People can directly use my patch anyway, or an Ubuntu package indeed (I need to update it). Thanks!
mallum; any movement on this? Would be nice to get it upstream and into distro packages so we can make the OLPC emulator/testbed story more complete as quickly as we can...
(In reply to comment #9) > mallum; any movement on this? Would be nice to get it upstream and into distro > packages so we can make the OLPC emulator/testbed story more complete as quickly > as we can... Hi, Im wondering with the size of the patch ( esp. when compared too Xephyr source size ) and it being very *specific* to the hardware, its maybe not better kept as its own kdrive server ( i.e Xswizzle ) in its own driver directory. To avoid a load of code duplication it could pull in Xehyr's core like other servers ( Xati ) pull in parts of Xvesa or Xfbdev.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Manu Cornet Do you still experience this issue with newer soft ? Please check the status of your issue.
This patch very much no longer applies. The idea is interesting, but at this point we should probably prefer to do this with a fragment shader in glamor.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.