Hi Laurent,
On 07/31/2011 11:28 PM, Laurent Pinchart wrote:
Hi Florian,
Thanks for the feedback.
On Monday 01 August 2011 00:54:48 Florian Tobias Schandinat wrote:
On 07/31/2011 08:32 PM, Geert Uytterhoeven wrote:
On Thu, Jul 28, 2011 at 12:51, Laurent Pinchart wrote:
As for struct fb_var_screeninfo fields to support switching to a FOURCC
mode, I also prefer an explicit dedicated flag to specify switching to
it. Even though using FOURCC doesn't fit under the notion of a
videomode, using one of .vmode bits is too tempting, so, I would
actually take the plunge and use FB_VMODE_FOURCC.
Another option would be to consider any grayscale> 1 value as a FOURCC.
I've briefly checked the in-tree drivers: they only assign grayscale
with 0 or 1, and check whether grayscale is 0 or different than 0. If a
userspace application only sets grayscale> 1 when talking to a driver
that supports the FOURCC-based API, we could get rid of the flag.
What can't be easily found out is whether existing applications set
grayscale to a> 1 value. They would break when used with FOURCC-aware
drivers if we consider any grayscale> 1 value as a FOURCC. Is that a
risk we can take ?
I think we can. I'd expect applications to use either 1 or -1 (i.e.
all ones), both are
invalid FOURCC values.
Still, I prefer the nonstd way.
And limiting traditional nonstd values to the lowest 24 bits (there
are no in-tree
drivers using the highest 8 bits, right?).
Okay, it would be okay for me to
- write raw FOURCC values in nonstd, enable FOURCC mode if upper byte != 0
- not having an explicit flag to enable FOURCC
- in FOURCC mode drivers must set visual to FB_VISUAL_FOURCC
- making support of FOURCC visible to userspace by capabilites |=
FB_CAP_FOURCC
The capabilities is not strictly necessary but I think it's very useful as
- it allows applications to make sure the extension is supported (for
example to adjust the UI)
- it allows applications to distinguish whether a particular format is not
supported or FOURCC at all
- it allows signaling further extensions of the API
- it does not hurt, one line per driver and still some bytes in fixinfo
free
Without a FOURCC capability applications will need to try FOURCCs blindly.
Drivers that are not FOURCC aware would then risk interpreting the FOURCC as
something else. As you mention below applications will need that check that
visual == FB_VISUAL_FOURCC, so it's less of an issue than I initially thought,
but it doesn't become a non-issue. The display might still show glitches.
True.
So using it would look like this:
- the driver must have capabilities |= FB_CAP_FOURCC
- the application may check capabilities to know whether FOURCC is
supported - the application may write a raw FOURCC value in nonstd to
request changing to FOURCC mode with this format
- when the driver switches to a FOURCC mode it must have visual =
FB_VISUAL_FOURCC and the current FOURCC format in nonstd
- the application should check visual and nonstd to make sure it gets what
it wanted
So if there are no strong objections against this I think we should
implement it. I do not really care whether we use a union or not but I
think if we decide to have one it should cover all fields that are
undefined/unused in FOURCC mode.
Hope we can find anything that everyone considers acceptable,
This sounds good to me, except that I would use the grayscale field instead of
the nonstd field. nonstd has pretty weird usecases, while grayscale is better
defined. nonstd might also make sense combined with FOURCC-based modes, while
grayscale would be completely redundant.
What's your opinion on that ?
I do not really care, either one would be okay for me.
You're right that nonstd is used for a lot of things and perhaps some of those
should still be possible in FOURCC mode. On the other hand I think applications
are more likely to pass random values to grayscale as its meaning seems globally
accepted (in contrast to nonstd where the application needs to know the driver
to get any use of it).
Perhaps you should also say that in FOURCC mode all unused pixel format fields
should be set to 0 by the application and other values of those may get a
meaning in later extensions or individual drivers.
Regards,
Florian Tobias Schandinat
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
