Announcement

Collapse
No announcement yet.

Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by Artim View Post
    Are you seriously trying to prove your point with a software that doesn't seem to be running on Linux for two decades and doesn't really have any information on how it actually did handle HDR content in Linux? You really have to be desperate.
    The open source world has a mirror to the software colord but even with that it does not make it work right. The reality is windows does not have proper metadata and depends on application rendering client side doing it colors right. The SDR abstraction Microsoft added for HDR is very much like running two X11 servers yes this shows up when at times your SDR colors are wrong and settings to correct it appear being ingored until you either restart windows or stop all SDR applications and start again. Yes the abstraction at times in Windows 10 decides not to take new values.

    Artim the reality here is every major desktop OS is a buggy mess when it comes to HDR.

    When Wayland does finally provide proper HDR metadata about the screen this will be a level above what Windows has been doing.

    The software I pointed to is what you have to use under windows to try to get the HDR/SDR stuff to look right. Please not try it does not properly succeed either.

    Colord on the open source is just as flawed.

    Yes Colord is a independent to graphical stack protocol color profile server solution for X11 and Wayland like the one I pointed to for Windows and Mac OS. Except colord is is free and open source on the Linux/BSD... platforms.

    The reality is you can get HDR to work with X11 with little extra horrible. Yes its working around the limitations of the X11 protocol not having the X11 protocol be that helpful. Yes HDR under Windows and Mac OS you also have to work around the limitations and that end up being having to buy bits of software to replace bits you get in the open source side of Linux for free so it somewhat works right.

    I do hope HDR mess does improve at some point to be correctly functional out the box when you install a operating systems not the current mess of no matter what OS you install you have to be jumping through hoops so it works right.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by billyswong View Post

    I sorta disagree with "most (HDR) apps should do their own color management if at all possible". Unless a software is designed for non-composited fullscreen use and the computer is always displaying it through the same monitor, all the nuances in HDR mapping is probably better delegated to be managed by the desktop compositor, else it would be a pile of mess.

    For example, if two apps want to display their HDR encoded material at the same time but their material are encoded in different HDR format, what should they do? Let them fight in a boxing ring?
    even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

    as you have different kinds of HDR, (dolby, HDR10 etc.). the issue I have is because HDR is so... annoying to work with, I think leaving it to the app to do color management is best if possible. it's not that they should have to do color management. but if possible it should be delegated to the app to do it. and ofc the hope would be to support at least fullscreen HDR at the least since a good chunk of HDR media consumption would work with this.

    I use MPV as an example because it's so darn powerful, I think wayland should be able to communicate color management and all, but all said and done, if the app can do it, the app should probably do it, (though the app should allow a toggle to let the compositor do it). and bypass as much as possible.

    Leave a comment:


  • Artim
    replied
    Originally posted by oiaohm View Post

    https://www.helios.de/web/EN/solutions/hd-color.html

    Except the color management bits for HDR are not included under Windows or MacOS its add a third party color management solution and then have the applications render correctly.

    There is well done HDR that has metadata about it that transfers useful stuff. Then what Windows, MacOS, X11 .... does what is basically have a color management server and throw the job on the applications todo the colour corrections right..

    That you took issue with my second paragraph means you are not really aware how its implemented generally. Mostly HDR is done poorly everywhere. Maybe Wayland will give is one done decently in time.
    Are you seriously trying to prove your point with a software that doesn't seem to be running on Linux for two decades and doesn't really have any information on how it actually did handle HDR content in Linux? You really have to be desperate.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Artim View Post
    And still all wrong. Of course I didn't waste my time to read that whole novel of yours, but your second paragraph already proves that you don't understand what you are talking about. Just because the X Server can be set to up to 16 bit color depth doesn't mean it can actually handle HDR. For that it would need what's actually in the works for Wayland: a way to communicate HDR metadata and to actually display content probably, aka color management. This was never included and will never be included. So say what you want, but X only has the theoretical capability to handle HDR, it doesn't have the real world tools for that.
    https://www.helios.de/web/EN/solutions/hd-color.html

    Except the color management bits for HDR are not included under Windows or MacOS its add a third party color management solution and then have the applications render correctly.

    There is well done HDR that has metadata about it that transfers useful stuff. Then what Windows, MacOS, X11 .... does what is basically have a color management server and throw the job on the applications todo the colour corrections right..

    That you took issue with my second paragraph means you are not really aware how its implemented generally. Mostly HDR is done poorly everywhere. Maybe Wayland will give is one done decently in time.

    Leave a comment:


  • Artim
    replied
    Originally posted by oiaohm View Post

    https://linuxreviews.org/HOWTO_enabl...color_on_Linux

    Artim what you wrote is wrong. Yes X11 can do HDR like early Wayland very badly. Its not circumvent X11 because X11 allows you to set the color depth of HDR. Problem is the limitation.

    X11 has had a core fault around multi color depths. I remember applications that need 16 bit and 8 bit color(also called 256 color) get those to work with X11 with other 24 bit applications you end up running X11 inside X11. X11 protocol you have exactly 1 colour depth per X11 server to be to protocol and all applications connecting to the X11 server are meant to match the servers color depth and color conversions.

    Wayland with the color management and all color conversions is looking to have multi color depths and color corrections handled by a single server.

    Yes wayland has stack-able compositors to implment HDR in workable/broken form following the X11 model you with have the direct screen connect compositor at HDR then then a proxy compositor like gamescope doing SDR and so on.

    Artim just because something is not done well does not mean it cannot be done. HDR on X11 is not circumvent of X11. Stacking X11 servers for different color depths is really how the X11 protocol defines as the way to do this. Remember this starts with 8bit /256 color on what was called 16 bit color wayback in history of X11. As you stack X11 servers drag and drop, copy paste and so on start getting more and more odd ball issues coming out. Are these X11 odd ball faults unique because you are running HDR no they are the same doing 8bit/256 color on SDR/24 bit color with X11. X11 design for handling multi color depths is just absolutely horrible and leads to a lot of different broken.

    Somethings we absolutely don't want implemented how X11 did them. Handling multi color depths on the same screen is absolutely one of those things we should all want done differently. This is also the problem when people say why did not Wayland come with all X11 features implemented out the box. Problem is some of those features need to be totally taken back to the drawing board and implemented from scratch because the existing X11 way may kind of work but its a path to lot of wacky issues.

    I don't really think anyone wants to use the stacked X11 server/ compositors method to have HDR support with SDR applications. Even that it is a valid way to make it work. The first weston release supported the stacked solution. So HDR support with Wayland is something that was not different to how X11 did it from the start line but in reality we don't want to do HDR/SDR that way.

    The X11 HDR/multi color depth solution is just the most horrible way implement this of course people like birdie incorrectly presume that Wayland cannot do the same thing when in fact wayland solutions can because wayland protocol was designed to include compositor stacking from day one can but in reality don't really want to go this path with all the issues it brings. Yes it will take longer as developers design a new solution for multi color depths that properly works instead of the history X11 solution of just stack servers/compositors to make it work.

    There is a worse issue the copy paste issue copy paste between pure wayland applications was perfectly from day one. Copy past from Xwayland to other wayland applications got a bit questionable for a while. But thing people like to forget copy paste X11 to X11 application does not always behave itself either because how to perform copy paste under X11 is not properly defined in the X11 protocol leading to a quirky mess that mostly works due to applications and toolkits on Linux containing a stack of quirk workarounds.
    And still all wrong. Of course I didn't waste my time to read that whole novel of yours, but your second paragraph already proves that you don't understand what you are talking about. Just because the X Server can be set to up to 16 bit color depth doesn't mean it can actually handle HDR. For that it would need what's actually in the works for Wayland: a way to communicate HDR metadata and to actually display content probably, aka color management. This was never included and will never be included. So say what you want, but X only has the theoretical capability to handle HDR, it doesn't have the real world tools for that.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by billyswong View Post
    Hmm... why would two "SDR" applications want different HDR conversions when displayed on the same HDR monitor? You mean those wide gamut stuff invented before we have Rec.2020, such as AdobeRGB and ProPhotoRGB? Oh that's another can of worm. Or do you mean the ambiguity caused by "HDR" monitors often unable to output physically an actual color range of P3, let alone the even wider Rec.2020?
    https://en.wikipedia.org/wiki/File:C...P3_Rec2020.svg

    Yes there is non standard monitors from the SDR time frame calibrated for different colour spaces. Yes I was referencing those different gamut ranges. Yes your SDR sRGB monitors don't all do sRGB properly either.

    Monitor calibration is a can of worms of it self. Then you have the different standards.

    BenQ SW240 24.1in Adobe RGB IPS Photography Monitor

    This is example of O my curse. There are SDR monitors that are in fact calibrated for AdobeRGB instead of sRGB. So yes you have SDR applications expecting screen sRGB gamut and SDR applications expecting screen to be AdobeRGB gamut. Of course people with a HDR monitor want all these if possible to now work on one screen.

    P3 has less range than a to standard AdobeRGB SDR monitor so it cannot replicate it. Rec 2020 can emulate sRGB and AdobeRGB SDR.

    Yes next level of fun monitors have their own unique/massively different calibration.

    The HDR problem is a true nightmare. This was coming a nightmare before we add HDR into the mix but this nightmare was like have 4 monitors on your desk all calibrated different and having to remember one what you had to put what application on so the output was in fact correct. Really bad to get something back from the print shop to find all the colors horrible out only to work out you had screwed up and opened the application on the wrong monitor so now need to redo everything.

    Leave a comment:


  • billyswong
    replied
    Originally posted by oiaohm View Post

    That not the worst part here. You have two different SDR applications attempting to be displayed on HDR and to look right they can need different HDR conversion.

    HDR output turns out to be a hot nightmare. Remember colour corrections very quickly can eat up a lot of CPU and GPU time.
    Hmm... why would two "SDR" applications want different HDR conversions when displayed on the same HDR monitor? You mean those wide gamut stuff invented before we have Rec.2020, such as AdobeRGB and ProPhotoRGB? Oh that's another can of worm. Or do you mean the ambiguity caused by "HDR" monitors often unable to output physically an actual color range of P3, let alone the even wider Rec.2020?

    It is very annoying seeing those HDR and WCG technology often ignore or under specify how they will coexist with narrow gamut or SDR material, especially when monitors so far still haven't truly matched Rec.2020. If HDR WCG monitors can be widely expected to display Rec.2020 correctly, then we can just specify non-color-managed or sRGB-specified material to display in sRGB within those monitors. Same for material in AdobeRGB and P3.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Artim View Post
    Wrong from beginning to end. X11 has absolutely no way to handle HDR and will never have. You can only use HDR as long as you circumvent X11 altogether, as most modern features do. They don't even bother talking to the X Server, they simply talk to the GPU. What is in the works for Wayland is actual HDR support including color management so all color conversions are handled
    https://linuxreviews.org/HOWTO_enabl...color_on_Linux

    Artim what you wrote is wrong. Yes X11 can do HDR like early Wayland very badly. Its not circumvent X11 because X11 allows you to set the color depth of HDR. Problem is the limitation.

    X11 has had a core fault around multi color depths. I remember applications that need 16 bit and 8 bit color(also called 256 color) get those to work with X11 with other 24 bit applications you end up running X11 inside X11. X11 protocol you have exactly 1 colour depth per X11 server to be to protocol and all applications connecting to the X11 server are meant to match the servers color depth and color conversions.

    Wayland with the color management and all color conversions is looking to have multi color depths and color corrections handled by a single server.

    Yes wayland has stack-able compositors to implment HDR in workable/broken form following the X11 model you with have the direct screen connect compositor at HDR then then a proxy compositor like gamescope doing SDR and so on.

    Artim just because something is not done well does not mean it cannot be done. HDR on X11 is not circumvent of X11. Stacking X11 servers for different color depths is really how the X11 protocol defines as the way to do this. Remember this starts with 8bit /256 color on what was called 16 bit color wayback in history of X11. As you stack X11 servers drag and drop, copy paste and so on start getting more and more odd ball issues coming out. Are these X11 odd ball faults unique because you are running HDR no they are the same doing 8bit/256 color on SDR/24 bit color with X11. X11 design for handling multi color depths is just absolutely horrible and leads to a lot of different broken.

    Somethings we absolutely don't want implemented how X11 did them. Handling multi color depths on the same screen is absolutely one of those things we should all want done differently. This is also the problem when people say why did not Wayland come with all X11 features implemented out the box. Problem is some of those features need to be totally taken back to the drawing board and implemented from scratch because the existing X11 way may kind of work but its a path to lot of wacky issues.

    I don't really think anyone wants to use the stacked X11 server/ compositors method to have HDR support with SDR applications. Even that it is a valid way to make it work. The first weston release supported the stacked solution. So HDR support with Wayland is something that was not different to how X11 did it from the start line but in reality we don't want to do HDR/SDR that way.

    The X11 HDR/multi color depth solution is just the most horrible way implement this of course people like birdie incorrectly presume that Wayland cannot do the same thing when in fact wayland solutions can because wayland protocol was designed to include compositor stacking from day one can but in reality don't really want to go this path with all the issues it brings. Yes it will take longer as developers design a new solution for multi color depths that properly works instead of the history X11 solution of just stack servers/compositors to make it work.

    There is a worse issue the copy paste issue copy paste between pure wayland applications was perfectly from day one. Copy past from Xwayland to other wayland applications got a bit questionable for a while. But thing people like to forget copy paste X11 to X11 application does not always behave itself either because how to perform copy paste under X11 is not properly defined in the X11 protocol leading to a quirky mess that mostly works due to applications and toolkits on Linux containing a stack of quirk workarounds.

    Leave a comment:


  • Artim
    replied
    Originally posted by oiaohm View Post

    You can set color depth 30 or higher with different wayland compositors and watch all majoritiy of the Wayland applications bite the dust as well yet some work.

    https://wiki.archlinux.org/title/HDR_video_playback

    As noted here Neither X11 or Wayland support HDR meta data. The stuff you need to run two different color depths from 2 different applications outputting on the same screen.

    Wayland DRM lease protocol is support by wayland and equal exist under X11. What is this a direct DRM application under Linux can go basically to what color bit depth it wants on screen include HDR but this is also exclusive control of the screen. Is there a identical way todo HDR under X11 and Wayland that does not break SDR yes there is lease the screen and be dual monitor or use a different TTY for the lease.

    HDR support in Wayland currently is implemented exactly as badly as X11..
    Wrong from beginning to end. X11 has absolutely no way to handle HDR and will never have. You can only use HDR as long as you circumvent X11 altogether, as most modern features do. They don't even bother talking to the X Server, they simply talk to the GPU. What is in the works for Wayland is actual HDR support including color management so all color conversions are handled

    Leave a comment:


  • oiaohm
    replied
    Originally posted by billyswong View Post
    I sorta disagree with "most (HDR) apps should do their own color management if at all possible". Unless a software is designed for non-composited fullscreen use and the computer is always displaying it through the same monitor, all the nuances in HDR mapping is probably better delegated to be managed by the desktop compositor, else it would be a pile of mess.

    For example, if two apps want to display their HDR encoded material at the same time but their material are encoded in different HDR format, what should they do? Let them fight in a boxing ring?
    That not the worst part here. You have two different SDR applications attempting to be displayed on HDR and to look right they can need different HDR conversion.

    HDR output turns out to be a hot nightmare. Remember colour corrections very quickly can eat up a lot of CPU and GPU time.

    Leave a comment:

Working...
X