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,
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"
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).
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.
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.