Michel Dänzer wrote:
> It was never reliable for that. Other clients using any of those
> mechanisms could always interfere, at least for the RandR compatibility
> output.
I disagree. It was reliable in the sense that running the
profile loader set it to a known state, irrespective
of whatever
Hello All,
We have raised a new merge request, for the HDR implementation in Weston:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/124
This patch series is in continuation to the design we published here:
On Sat, 9 Mar 2019 16:02:44 -0700
Chris Murphy wrote:
> Call me crazy but I'd like to think GTK or Qt could provide, if they
> so chose, this abstraction such that a display profiling app could run
> on any platform with any compositor, and calibrate or profile. These
> higher level APIs should
On Fri, Mar 8, 2019 at 3:31 AM Pekka Paalanen wrote:
>
> On Fri, 8 Mar 2019 08:35:20 +1100
> Graeme Gill wrote:
>
> > Michel Dänzer wrote:
> >
> > > It sounds like KMS leases could be a pretty good fit for a calibration
> > > application. It can lease each output individually from the Wayland
>
On Fri, 8 Mar 2019 08:35:20 +1100
Graeme Gill wrote:
> Michel Dänzer wrote:
>
> > It sounds like KMS leases could be a pretty good fit for a calibration
> > application. It can lease each output individually from the Wayland
> > compositor and fully control it using KMS APIs, while the Wayland
On 2019-03-08 9:41 a.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>
>> It was never reliable for that. Other clients using any of those
>> mechanisms could always interfere, at least for the RandR compatibility
>> output.
>
> I disagree. It was reliable in the sense that running the
> profile
On 2019-03-07 10:07 p.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>
>> Yep. The alternative is that the different mechanisms clobber the
>> hardware LUT from each other, which sucks from a user POV.
>
> Which user though ?
>
> It certainly does the opposite of suck if you are a user
> who
On Thu, Mar 7, 2019 at 2:35 PM Graeme Gill wrote:
>
> Michel Dänzer wrote:
>
> > It sounds like KMS leases could be a pretty good fit for a calibration
> > application. It can lease each output individually from the Wayland
> > compositor and fully control it using KMS APIs, while the Wayland
> >
Michel Dänzer wrote:
> It sounds like KMS leases could be a pretty good fit for a calibration
> application. It can lease each output individually from the Wayland
> compositor and fully control it using KMS APIs, while the Wayland
> compositor continues running normally on other outputs.
There
Michel Dänzer wrote:
> As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all
> relevant mappings (colormap, global gamma, xf86VidMode per-X-screen
> ramp, RandR per-CRTC ramp) are composed, and the result is applied to
> the hardware LUT for all CRTCs.
It's disappointing a
Chris Murphy wrote:
Hi Chris,
> Not every desktop environment is using the same Wayland compositor, or
> even a Wayland compositor at all. So is drm/kms something you can
> depend on most of the time regardless of the desktop?
I'm sure you could get even wider coverage of color management
tools
On Thu, Mar 7, 2019 at 3:15 AM Michel Dänzer wrote:
>
> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
> > Of course. It can take 5-30 minutes to do a calibration and
> > characterization. In particular if I have 2, 3 or even 4 displays
> > connected I'd want to calibrate them in sequence while
On 2019-03-07 1:43 p.m., Kai-Uwe wrote:
> Am 07.03.19 um 11:15 schrieb Michel Dänzer:
>> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
>>> On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
[ And why should Linux/Wayland be crippled compared to
every other system ? I can and do do
Am 07.03.19 um 11:15 schrieb Michel Dänzer:
> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
>> On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>>> [ And why should Linux/Wayland be crippled compared to
>>> every other system ? I can and do do things like fire up
>>> a test patch display
Am 07.03.2019 um 05:26 schrieb Chris Murphy:
> Hmmm. For a while now we've had display calibration+profiling
> applications compel full screen mode
While some calibration/profiing applications are able to display a
fullscreen window for the patch area (some may even default to it), I
know none
On 2019-03-07 8:05 a.m., Chris Murphy wrote:
> On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>>
>> Chris Murphy wrote:
>>
>>> Hmmm. For a while now we've had display calibration+profiling
>>> applications compel full screen mode so they're not really usable
>>> alongside anything else. They
On 2019-03-07 5:38 a.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>> As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all
>> relevant mappings (colormap, global gamma, xf86VidMode per-X-screen
>> ramp, RandR per-CRTC ramp) are composed, and the result is applied to
>> the
On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>
> Chris Murphy wrote:
>
> > Hmmm. For a while now we've had display calibration+profiling
> > applications compel full screen mode so they're not really usable
> > alongside anything else. They are in effect taking over. So if it's
> > possible
Chris Murphy wrote:
> Hmmm. For a while now we've had display calibration+profiling
> applications compel full screen mode so they're not really usable
> alongside anything else. They are in effect taking over. So if it's
> possible for the calibration app to set aside the Wayland session, use
>
Michel Dänzer wrote:
> As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all
> relevant mappings (colormap, global gamma, xf86VidMode per-X-screen
> ramp, RandR per-CRTC ramp) are composed, and the result is applied to
> the hardware LUT for all CRTCs.
Hmm. Yuk from a color
Adam Jackson wrote:
> Sure, but one would not expect to control the display's global
> calibration state from an X client in this model, for broadly the same
> reasons that RANDR under Xwayland is read-only. The wayland server owns
> that state, the Xwayland server is simply a very demanding
On Wed, Mar 6, 2019 at 7:12 PM Graeme Gill wrote:
>
> Carsten Haitzler wrote:
> > for the purposes of calibration, imho a calibration tool should just use
> > drm/kms directly and run in a console outside of wayland.
>
> Sorry, but that's a total non-starter. Calibration & profiling
> tools are
Carsten Haitzler wrote:
> On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said:
> it involves a screen or set of screens "flashing" between different
> colorspaces. it's much the same kind of effect of ye olde colormap installs.
> not as extreme, but still the entire screen content changing
On Wed, Mar 6, 2019 at 3:15 AM Carsten Haitzler wrote:
>
> for the purposes of calibration, imho a calibration tool should just use
> drm/kms directly and run in a console outside of wayland. it then owns the
> display. it's not like it's a commonly used tool (likely once on purchase of a
> gpu
On 2019-03-06 5:00 p.m., Adam Jackson wrote:
> On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote:
>> Adam Jackson wrote:
>>
>>> The second, which games typically use, is setting per-channel gamma
>>> (implicitly for the whole screen) as single floating-point values with
>>> the xf86vidmode
On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote:
> Adam Jackson wrote:
>
> > X kinda has three mechanisms for this. The first one, that nobody
> > really uses, is setting the colormap for a DirectColor visual.
>
> Actually this is something I check and set to linear before
> calibration &
On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said:
> Carsten Haitzler (The Rasterman) wrote:
> > apps should not have exclusive access. we're re-doing the whole horrid
> > "install colormap" thing from the x days of 256 color (or
> > paletted/colormapped displays).
>
> It's not quite the same
Pekka Paalanen wrote:
> I presume the measurement or calibration use case always involves
> "owning" the whole monitor, and the very specific monitor at that. That
> is, making the monitor temporarily exclusive to the app, so that
> nothing else can interfere (e.g. instant messaging notification
Carsten Haitzler (The Rasterman) wrote:
> apps should not have exclusive access. we're re-doing the whole horrid
> "install
> colormap" thing from the x days of 256 color (or paletted/colormapped
> displays).
It's not quite the same thing in all cases.
A game doing this - yes, it's setting it
Simon Ser wrote:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote:
>> 2) Implement virtual per channel LUTs, with the compositor combining them
>>together in some way, and have some means of the color management
>> applications
>>being aware when the display is being interfered
Adam Jackson wrote:
Hi,
> X kinda has three mechanisms for this. The first one, that nobody
> really uses, is setting the colormap for a DirectColor visual.
Actually this is something I check and set to linear before
calibration & profiling in the ArgyllCMS tools.
> The
> second, which games
On Mon, Mar 4, 2019 at 3:20 AM Pekka Paalanen wrote:
>
> X11 apps have (hopefully) done hardware LUT manipulation only through
> X11. There was no other way AFAIK, unless the app started essentially
> hacking the system via root privileges.
>
> The current DRM KMS kernel design has always had a
On Mon, Mar 4, 2019 at 1:32 AM Simon Ser wrote:
>
> On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote:
> > And the current favorite is "blue light filter" effects, for which numerous
> > applications are currently available. They tweak the white point
> > of the display by arbitrarily
On Mon, Mar 4, 2019 at 12:13 AM Graeme Gill wrote:
>
> Chris Murphy wrote:
>
> > A common offender were games. They'd try to access the video card LUT
> > directly for effects, but then not reset it back to what it was,
> > rather reset it to a hardwired assumption the game makes,
>
> And the
On Monday, March 4, 2019 10:50 AM, Carsten Haitzler
wrote:
> > How should this look like? Disclaimer: I have no idea how these applications
> > work and I know nothing about color management.
> > I'm guessing this is a restriction of the "change the whole LUTs" API. Are
> > there any features
Am 04.03.19 um 09:32 schrieb Simon Ser:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote:
>> And the current favorite is "blue light filter" effects, for which numerous
>> applications are currently available. They tweak the white point
>> of the display by arbitrarily modifying the hardware
Chris Murphy wrote:
Hi Chris,
> Well you need a client to do display calibration which necessarily
> means altering the video LUT (to linear) in order to do the
> measurements from which a correction curve is computed, and then that
> client needs to install that curve into the video LUT. Now,
On Fri, 1 Mar 2019 12:47:05 -0700
Chris Murphy wrote:
> On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen wrote:
> >
> > On Thu, 28 Feb 2019 18:28:33 -0700
> > Chris Murphy wrote:
> >
> > > I'm curious how legacy applications including games used to manipulate
> > > actual hardware LUT in a
On Mon, 04 Mar 2019 08:32:45 + Simon Ser said:
> On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote:
> > And the current favorite is "blue light filter" effects, for which numerous
> > applications are currently available. They tweak the white point
> > of the display by arbitrarily
On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote:
> And the current favorite is "blue light filter" effects, for which numerous
> applications are currently available. They tweak the white point
> of the display by arbitrarily modifying the hardware per channel LUTs.
> (i.e. f.lux, Redshift,
Chris Murphy wrote:
> A common offender were games. They'd try to access the video card LUT
> directly for effects, but then not reset it back to what it was,
> rather reset it to a hardwired assumption the game makes,
And the current favorite is "blue light filter" effects, for which numerous
On Fri, 2019-03-01 at 12:10 +0200, Pekka Paalanen wrote:
> On Thu, 28 Feb 2019 18:28:33 -0700
> Chris Murphy wrote:
>
> > I'm curious how legacy applications including games used to manipulate
> > actual hardware LUT in a video card, if the application asked the
> > client to do it, in which
On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen wrote:
>
> On Thu, 28 Feb 2019 18:28:33 -0700
> Chris Murphy wrote:
>
> > I'm curious how legacy applications including games used to manipulate
> > actual hardware LUT in a video card, if the application asked the
> > client to do it, in which case
On Thu, 28 Feb 2019 18:28:33 -0700
Chris Murphy wrote:
> On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen wrote:
> >
> > On Wed, 27 Feb 2019 13:47:07 -0700
> > Chris Murphy wrote:
> >
> > > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > there is a single,
On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen wrote:
>
> On Wed, 27 Feb 2019 13:47:07 -0700
> Chris Murphy wrote:
>
> > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
> > >
> > > there is a single, unambiguous answer on Wayland: the compositor owns
> > > the pipeline. Therefore we won't
On Wed, 2019-02-27 at 13:47 -0700, Chris Murphy wrote:
> On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
> > there is a single, unambiguous answer on Wayland: the compositor owns
> > the pipeline. Therefore we won't have the kind of problems you describe
> > above.
> >
> > These are the
On Wed, 27 Feb 2019 13:47:07 -0700
Chris Murphy wrote:
> On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
> >
> > there is a single, unambiguous answer on Wayland: the compositor owns
> > the pipeline. Therefore we won't have the kind of problems you describe
> > above.
> >
> > These are
On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
>
> there is a single, unambiguous answer on Wayland: the compositor owns
> the pipeline. Therefore we won't have the kind of problems you describe
> above.
>
> These are the very reasons I am against adding any kind of protocol
> extension
On Fri, 22 Feb 2019 14:18:44 -0700
Chris Murphy wrote:
> On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen wrote:
> >
> > Hi Chris,
> >
> > that is some interesting background, but I feel like I didn't quite
> > catch the point.
> >
> > If the CRTC color management pipeline (LUT-CTM-LUT + maybe
On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen wrote:
>
> Hi Chris,
>
> that is some interesting background, but I feel like I didn't quite
> catch the point.
>
> If the CRTC color management pipeline (LUT-CTM-LUT + maybe more) is
> programmed according to the monitor's color profile, where would
On Mon, 18 Feb 2019 10:44:15 -0700
Chris Murphy wrote:
> On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen wrote:
> >
> > On Thu, 31 Jan 2019 12:03:25 -0700
> > Chris Murphy wrote:
> >
> > > I'm pretty sure most every desktop environment and distribution have
> > > settled on colord as the
On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen wrote:
>
> On Thu, 31 Jan 2019 12:03:25 -0700
> Chris Murphy wrote:
>
> > I'm pretty sure most every desktop environment and distribution have
> > settled on colord as the general purpose service.
> > https://github.com/hughsie/colord
> >
Hello Chris,
Am 31.01.19 um 20:03 schrieb Chris Murphy:
> On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
> wrote:
>> From where can the client-applications get the ICC profile files? Does
>> the client application manufacture it for a given color space and a
>> standard template?
> I'm
Chris Murphy wrote:
Hi Chris,
> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/
right, but colord is not needed to run X11 color
Pekka Paalanen wrote:
> Graeme Gill wrote:
Hi,
>> I don't have any basis to voice an opinion as to which particular protocol
>> these different aspects would best fall into (wayland core or one of the
>> supplementary xdg protocols ? - I'm not clear on what the purpose of these
>> divisions
On Thu, 31 Jan 2019 12:03:25 -0700
Chris Murphy wrote:
> Hi Ankit,
>
>
> On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
> wrote:
> >
> > Hi Ole,
> >
> > I was going through the protocol you had proposed, and have some silly
> > questions, please pardon my ignorance.
> >
> > From where
Hi Ankit,
On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
wrote:
>
> Hi Ole,
>
> I was going through the protocol you had proposed, and have some silly
> questions, please pardon my ignorance.
>
> From where can the client-applications get the ICC profile files? Does
> the client
is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content/buffers are composed in REC2020 colorspace
top.org/archives/wayland-devel/2014-March/013951.ht
> > ml
> >
> > Best regards,
> > Ole
> >
> > Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank:
> >> Hello All,
> >>
> >> This mail is to propose a design for
, Shashank:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content
On Tue, 29 Jan 2019 16:02:16 +1100
Graeme Gill wrote:
> Pekka Paalanen wrote:
>
> >>> Yes, a compositor must implement all that, but this is now slipping to
> >>> the topic of calibration, which is very much off-scope for today. We
> >>> only want to consider how applications produce and
Pekka Paalanen wrote:
> yes, this is a good concern. I think we might be needing an extension
> to tell the client which output to prioritise for. We already have an
> analogue of that in the Presentation-time extension: a wl_surface's
> timings can only be synchronised to one output at a time,
>>> On Thu, 10 Jan 2019 20:32:18 +0530
> >>> "Sharma, Shashank" wrote:
> >>>
> >>>> Hello All,
> >>>>
> >>>> This mail is to propose a design for enabling HDR support in
> >>>> Wayland/Weston st
On Fri, 18 Jan 2019 19:02:01 +1100
Graeme Gill wrote:
> Pekka Paalanen wrote:
>
> Hi,
>
> > If a wl_surface straddles multiple outputs simultaneously, then
> > wl_surface.enter/leave events indicate the surface being on all those
> > outputs at the same time. The client is expected to take all
Am 18.01.19 um 09:08 schrieb Graeme Gill:> Maybe rendering specifically
for one output is sufficient
> as long as the secondary displays (however that is determined!) look
> OK with a fallback conversion by the compositor.
Currently the first or main monitor is the primary rendering target. As
Sharma, Shashank wrote:
Hi,
> Yes, this is very accurate. We are planning to add a protocol extension,
> which will allow
> a client to pass the buffers colorspace information to the compositor. And
> compositor
> already has HW's color capabilities (drm properties per plane and CRTC), and
>
Adam Jackson wrote:
Hi,
> This isn't necessarily true. The server is free to just draw a black
> rectangle (or nothing) instead if the image doesn't match the target
> colorspace. If you want to handle the case of cloned outputs or
> crossing output borders, let the client attach one image per
Pekka Paalanen wrote:
Hi,
> If a wl_surface straddles multiple outputs simultaneously, then
> wl_surface.enter/leave events indicate the surface being on all those
> outputs at the same time. The client is expected to take all the
> entered outputs into consideration when it chooses how to
design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
*snip*
I understand your aim is to leverage display hardware capabilities to
the fullest, but we must also consider hardware that lacks some or all
of th
On Tue, 15 Jan 2019 14:14:53 -0500
Adam Jackson wrote:
> On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> > On Tue, 15 Jan 2019 13:47:07 +1100
> > Graeme Gill wrote:
> >
> > > If done in the composer, it would need to render the graphic elements to
> > > the output DPI / convert
On Tue, 15 Jan 2019 13:19:00 +0100
Niels Ole Salscheider wrote:
> Am Dienstag, 15. Januar 2019, 10:30:14 CET schrieb Pekka Paalanen:
> > Yes and no. Yes, we do and should let clients know what kind of outputs
> > their contents will be shown on. However, we will in any case need the
> >
On Wed, 16 Jan 2019 09:25:06 +0530
"Sharma, Shashank" wrote:
> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:
> > On Thu, 10 Jan 2019 20:32:18 +0530
> > "Sharma, Shashank" wrote:
> >
> >> Hello All,
> >>
> >> This mail is to pr
Hi Arnaud,
Thank you for the comments, please find mine inline.
Arnaud Vrac writes:
> On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank
> wrote:
>>
>> > The proposal is missing many important bits like negotiation of the
>> > supported output features with the client, double buffering the new
Hello All,
> >>
> >> This mail is to propose a design for enabling HDR support in
> >> Wayland/Weston stack, using display engine capabilities, and get more
> >> feedback and input from community.
> >> Here are few points (you might already
Hello Arnaud
Thanks for your comments, mine inline.
Regards
Shashank
On 1/17/2019 6:38 AM, Arnaud Vrac wrote:
On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
wrote:
Hello All,
This mail is to propose a design for enabling HDR support in Wayland/Weston
stack, using display engine
On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
wrote:
>
> Hello All,
>
> This mail is to propose a design for enabling HDR support in Wayland/Weston
> stack, using display engine capabilities, and get more feedback and input
> from community.
> Here are few points (y
Hello Graeme,
Thanks for your inputs and comment, please find mine inline.
Regards
Shashank
On 1/11/2019 12:55 PM, Graeme Gill wrote:
Sharma, Shashank wrote:
Hi,
While I'm sure you could hard code various color space assumptions into
such an implementation (and perhaps this is a pretty
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content/buffers ar
On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> On Tue, 15 Jan 2019 13:47:07 +1100
> Graeme Gill wrote:
>
> > If done in the composer, it would need to render the graphic elements to
> > the output DPI / convert the source colorspace to the output colorspace.
> > But the composer
Am Dienstag, 15. Januar 2019, 10:30:14 CET schrieb Pekka Paalanen:
> On Tue, 15 Jan 2019 13:47:07 +1100
>
> Graeme Gill wrote:
> > Pekka Paalanen wrote:
> >
> > Hi Pekka,
> >
> > thanks for your response.
> >
> > >> As far as I was informed, Wayland
> > >> is architected in such a way
On Tue, 15 Jan 2019 13:47:07 +1100
Graeme Gill wrote:
> Pekka Paalanen wrote:
>
> Hi Pekka,
> thanks for your response.
>
> >> As far as I was informed, Wayland
> >> is architected in such a way that this is not possible, since clients
> >> have no knowledge of which display the pixels
Pekka Paalanen wrote:
Hi Pekka,
thanks for your response.
>> As far as I was informed, Wayland
>> is architected in such a way that this is not possible, since clients
>> have no knowledge of which display the pixels they send will end up on.
>
> Nothing has changed there.
I've been
On Fri, 11 Jan 2019 18:25:01 +1100
Graeme Gill wrote:
> Sharma, Shashank wrote:
>
> Hi,
>
> While I'm sure you could hard code various color space assumptions into
> such an implementation (and perhaps this is a pretty reasonable way
> of doing a proof of concept), it's not a good long term
On Thu, 10 Jan 2019 20:32:18 +0530
"Sharma, Shashank" wrote:
> Hello All,
>
> This mail is to propose a design for enabling HDR support in
> Wayland/Weston stack, using display engine capabilities, and get more
> feedback and input from community.
> Here are few po
Sharma, Shashank wrote:
Hi,
While I'm sure you could hard code various color space assumptions into
such an implementation (and perhaps this is a pretty reasonable way
of doing a proof of concept), it's not a good long term solution,
and could end up being something of a millstone. What's
,
I will come back with my feedback for this stack, soon.
- Shashank
Best regards,
Ole
Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get
This mail is to propose a design for enabling HDR support in
> Wayland/Weston stack, using display engine capabilities, and get more
> feedback and input from community.
> Here are few points (you might already know these), about HDR
> framebuffers, videos and displays:
> - HDR content/buffers
If the block diagram is not aligned due to mail client, please refer to
the attached .txt file. Hope thats slightly better :).
Regards
Shashank
On 1/10/2019 8:32 PM, Sharma, Shashank wrote:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content
89 matches
Mail list logo
