The display has an 18-bit colour depth (262,000 or so possible colours) and is connected RGB565 to the MTL017. The MTL017 is connected RGB565 to the IPU.

To use the 18-bit depth of the panel you'd need to connect 18 to 24 bits from the IPU to the MTL017 and have it dither them down to the 16 to 18 bits connected to the panel.

A full 16 million colour panel would cost far more, I can't even find one from a quick search at suppliers. Using the 24-bit-input-to-16/18-bit-output version of the MTL017 would cost a few dollars more but on a few hundred thousand units that is a few hundred thousand dollars to take advantage of 2 bits per gun (if that..) - this is notwithstanding the extra layout required to route the extra display pins to the MTL017, or some other LVDS controller.

You would always lose colour definition, and at some point it was decided that it should just be a straight 16-bit to 16-bit connection from IPU right through to the panel making all the colour data transmitted exactly as source.

That was probably a bit of a bad idea.
I'm not sure what you mean here. There is a way to convert pixel data from a buffer and throw it at a Display Interface, but it's basically only if you have a YUV source and RGB destination, and works on pixel packing (i.e. it shifts all 16-bit pixels into 24-bit ones, or culls lower bits). You wouldn't gain anything, in fact it would probably lose even more colour data.
You don't like the keyboard?? That *is* a new one.

_________________
Matt Sealey

I also agree that the keyboard is simply excellent. I've never used a keyboard this good on a device this small.

I really look forward to the next revision/further devices.

hi johnson, Matt

hope you guys don't mind me jumping into the middle of the conversation, but I just pondered a bit about how/if the OP's color fidelity problem can be alleviated, and here are my general observations, feel free to correct me if you think otherwise:

Normally, in most color-quantizing display paths, the quantization step happens at the videosignal transmitter stage. There the transmitter usually offers a choice among a few algorithms, from bit-dropping to some non-fancy dithering. In our case the LVDS transmitter is of the dumb WYFMIWYG (what you feed me is what you get) type, and it only eats 16bit. To get dithering one needs to do something like:

1. keep an offscreen 24bit 'logical' fb,
2. blit that with dithering to onscreen 16-significant-bits 'physical' fb.
3. feed that latter to the IPU. In case physical fb's bpp is > 16 (which would be a waste of gpu memory, but let's throw it in for completeness), or RGB layout is not the correct one, let the IPU do the bit swizzling of the 16 significant bits.

A simple plan, eh? Not really. Two major questions stand out in it: (1) who will do the dithering in a performance-non-taxing manner, and (2) when/how often that needs to be done - clearly we want to get away with as few as possible ditherings.

(1) dictates that we should not be picky about the quality of dithering - we want something that 'just does dithering really fast'. Let's assume, for the sake of argument, that we have such a unit available there. Let's call it 'friendly blitter open to dithering proposals'.

Now all we need is to solve (2) and we're good! Unfortunately, the devil is in the details, and as a rule - in the last one, so here comes the wicked one.

Ideally, if we wanted to emulate the behavior of a dithering videosignal transmitter, we'd want to do our artificial dithering at every fb scanout, just before scanout. So, that makes what - V-refresh -worth-of ditherings over fb-worth of pixels? That might be a tad too much for our friendly blitter, who, apropos, might have other errands to take care of just as well. Errands we may not be able to interrupt for our hard-realtime needs. So that 'at scanout' approach is just not for us. What else is there? Well, of course - dithering at every fb update, but again, over the entire fb, to allow our dithering circuit to do its error-diffusion job. Good, so how do we cap our fb updates frequency? We don't - client apps may update/trigger updates to the root window at arbitrary rates. Heck, they could even do that faster than the scanout frequency! So, what am I saying here? I'm saying that if we want dithered X, we should be ready to pay _through_the_nose_ for it in performance currency. And that's is the reason why such tasks are best left to the video transmitter.

Now, who here is ready to pay through the nose? ; )

We are talking obviously past each other at this point, I better stop. :D
It is pretty good, but it could be better. The keys have the problem that they don't register keypresses if they aren't hit at their center. One side of the key will get pushed deeper because the switch acts like a lever. This is a big problem for the small arrow keys and a bit less of a problem with the other keys.

And yes, the arrow keys could be bigger :D And the keyboard maps F1-F12 to some dumb media keys by default, but I don't know if that was the default or done by me. *nagnag*
You are assuming that dithering is expensive, but is it really? Your whole argument falls apart without proving that it is indeed expensive.
just find out if the fb got changed since the last time you dithered it. (There are a lot of ways to get that information: Got the 3d pipeline used, did we use a double/tripple buffer and issued switch to another one? we could use in-kernel mechanisms to find out that there was indeed at least one write to a framebuffer)
Bad dithering is as bad as no dithering, because it doesn't look better and is easy to spot.
The driver has full control and is in the kernel. And dithering needs to be done/issued from there.
The X server and fbdev/driver regulate when, where and how something gets written to the framebuffer, so it doesn't matter if and how clients issue drawing commands.



I thought of the following 3 ways to attack the problem without involving gui toolkits:

(1) use the IPU to write out to RAM instead of the io pins every xth frame, then feed a dithered version back (IPU probably doesn't support that, doesn't work, switch between 16/32bit every frame in the IPU hardware is probably plain madness). (bad)
(2) do the mixing of 3d framebuffer and other framebuffers in software instead of the IPU, do dithering after the mixing in software, too, then feed that to the IPU. This would also remove all X related problems because all problems with "do we have to do dithering again" is simplified to has_framebuffer_changed().
(3) do the dithering by using fbdev and shadow buffers + some hacks (bad)

(2) would be the only way, but I'm not very interested given the time and the effort needed. And there is an mx53 version coming out and I'm not doing any art.

You can also use enlightenment, if you want a properly dithered window environment and don't care about which one.

All of which are extremely bandwidth intensive on an already bandwidth-starved SoC.

Dithering of the panel data is best done between output and conversion to LVDS. There is no good way to do it in software (certainly not hardware!) except your GUI toolkit

1) knows t's running below 24bit
2) dithers all rendering appropriately

We know GNOME's desktop manages it but the menus do not. This is a GNOME bug. The panel library probably doesn't use Cairo in the same way the desktop background thingy does.

Or we can use better panels or a better LVDS controller. That's a real solution that relies on nothing. There is no fix for current model as there is nothing technically wrong - it's aesthetic, like how the shiny plastic shows fingerprints. Annoying, but actually too common in industry for anyone to properly complain about (you'd think one day industry would pay attention and not make a super shiny system, and we're guilty of not thinking about it until it happened, and we're taking it into account).

That's the end of this discussion,.

_________________
Matt Sealey