wayland color depth 256 / 16 / 24 /32

Pekka Paalanen ppaalanen at gmail.com
Sun Jan 11 00:27:52 PST 2015


On Wed, 7 Jan 2015 16:53:43 +0100
Damian Ivanov <damianatorrpm at gmail.com> wrote:

> Hi,
> 
> What color depth works on wayland?

Wayland does not really care. The actual compositors and clients
would be the key here, and also the graphics driver implementations
(EGL, GL, etc.) where acceleration is desired.

If you need more buffer color formats added to the protocol for
wl_shm based buffers, we can do that quite easily, especially if
those formats have a widely accepted fourcc code.

However, adding paletted formats would be quite more work: define
a protocol extension, and implement support for it in compositors
and clients. I'm not sure that would be worth it: the client can
convert to a non-paletted format, and if that is too slow, then a
composited window system is perhaps too slow also.

> I haven't seen any configuration hint on this one,
> it would be nice to have 256 possible too, if it's not a total hack or
> brings an enormous amount of code.
> 
> Usecase would be, as soon as wine works native on wayland to run
> legacy 256 only apps. (There are a few of them)

I seem to recall that there are some other harder problems that are
much more blockers for porting Wine to Wayland than just color
depth. Color depth or pixel format issues are easily circumvented by
adding an intermediate buffer with some copying/converting, but the
other problems are more fundamental.

Perhaps a faster way to let Wine work on Wayland-based desktop
systems would be to improve Xwayland instead of Wine.

Do you know of anyone actually looking into the Wine on Wayland
matter?


Thanks,
pq


More information about the wayland-devel mailing list