So I was looking at the memory bandwidth limitations that ajax added
to the X server,
and how we could add the concept to KMS.

Now the X server is in a lucky position as when it gets the modes it also knows
what bit depth its going to run in, and it can use that at the mode
validation time
to remove modes for bandwidth reasons.

Now KMS doesn't know what bitdepth its users is going to use until
they associate
a modeset is done and the framebuffer is assigned to the crtc, however
failing to
set the mode at this stage would be rude as we never removed the mode
from the list.

I can see a few  solutions to this (some hacky some not):

1) add a new field to the mode getting ioctl, specifying what bit depth the user
would like to have the mode list validated against before returning,
this probably
means speccing a new ioctl since I think this one is full.

2) add a new ioctl to be set by the kms user app, which pretty much says
I'm interested in modes that can work at this bpp, with a default to
32-bit depth.

3) add some new flags to the modes, stating what bit sized depths they are
supported at (i.e. DRM_MODE_FLAG_8BIT, 16BIT, 32BIT, 64BIT etc)

4) pass the info about memory bw to the caller (i.e. X) - uggh no.

I'm sort of leaning towards 2 at the moment as its probably the simpler, just
wondering if anyone has any other ideas or preferences?

Dave.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to