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 birdie View Post
    In Linux tons of applications completely fall apart when you set your Xorg color bit depth to 30 or higher, including all Chromium/Electron based applications and Steam.
    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.



    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..

    Leave a comment:


  • Vistaus
    replied
    Originally posted by birdie View Post
    So, again you are quite insincere about Windows
    So I take your side, even going so far as calling you an expert (since you seem to know a lot about it) and you still say stuff like this? Why do you feel like you need to use that tone with me?

    If you want to respond like you do, why not respond to https://www.phoronix.com/forums/foru...43#post1325943 who called you a “arragant moron”?
    Last edited by Vistaus; 28 May 2022, 11:00 AM.

    Leave a comment:


  • billyswong
    replied
    Originally posted by Quackdoc View Post

    Im a little confused by this statement. we are not talking about color management as a whole. we are talking about HDR support, we have two immensely popular apps that already support HDR, that are widely used on linux it just so happens that neither of them work when used with x11 or wayland compositors because neither have support for HDR.

    is there more needed for other apps to play nice? sure probably so. but regardless all of it needs at least part of the equation. at least we would have at the minimum two very popular applications that will work. and I would argue that most apps should do their own color management if at all possible. well, apps oriented for HDR anyway
    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?

    Leave a comment:


  • birdie
    replied
    It's worth starting each discussion about Wayland with this poo.

    Needless to say it's closed for discussion, neglected and no one gives a fuck about it, just like the world continues not to give a fuck about the hot ugly mess of Linux on the desktop where nothing ever works or complete aside from absolute basic features like working with your storage or network.

    Audio? Graphics subsystem? Gaming? APIs? Oh, God.
    Last edited by birdie; 28 May 2022, 09:55 AM.

    Leave a comment:


  • birdie
    replied
    Originally posted by Vistaus View Post

    Ouch. Be careful what you say about HDR on Windows, 'cause last time I said something about it, I got a lenghty rant from HDR expert birdie. Bottom line was that it always works on Windows.
    It doesn't always work in Windows but it's not down to Microsoft or Windows. It's down to HDR [in terms of standards] being a hot mess. And where it matters it's worked perfectly for over a decade. Multiple content creation applications (photo/video editing/mastering, CADs, 3D modelling) all work perfectly under Windows. Applications don't fall apart when you enable 30/36bit color in Windows but they may continue to use 24bit colors.

    In Linux tons of applications completely fall apart when you set your Xorg color bit depth to 30 or higher, including all Chromium/Electron based applications and Steam.

    So, again you are quite insincere about Windows while in Linux we have fucking nothing in terms of proper HDR support.

    Forward looking modern Wayland has turned to be a huge pile of poo in terms of being useful.

    Leave a comment:


  • MrCooper
    replied
    Originally posted by cynic View Post

    I don't care what other people do, and I don't care to listen to what you think other people do.
    There was a simple question ("what is a feature you miss") and "network transparency" was my answer to that.
    Do you mind describing how you're using X11 network transparency then?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mdedetrich View Post
    Actually the biggest thing that Wayland and the linux ecosystem is missing is explicit sync support throughout the protocol, and thats causing many issues for all graphics vendors and this will take many years to resolve. All of the other OS's have moved to explicit sync decades ago.
    https://docs.microsoft.com/en-us/win...-to-directx-12

    Sorry windows all version all the though DX11 is still implicit sync in the compositor. That right Windows 7-8.1 in the graphic compositor the DWM is using Implicit sync not explicit sync. So it not decades ago its less than half a decade. Windows 10 still has options you can enable that will make DWM using implicit not explicit.

    Interest point the DX11 stuff Microsoft provides implements implicit sync on top of the driver explicit sync. There are different features Microsoft have mandated be include in the windows drivers so this works. Yes this implicit sync on top of the driver explicit sync with windows is implemented kernel side and integrated with the scheduler..

    There is a reason why compositors really do want to use something like a kernel implemented implicit sync it that compositor is not consuming CPU cycles that would let applications complete what they are doing.

    mdedetrich there is a reason why Vulkan protocol has to deal with implicit sync when it deals with the OS this is not just for Linux this is also for older versions of Windows. Not everyone is using Windows 10 and newer who are Windows users. Worse if you have enabled legacy driver compatibility with graphics drivers in Windows 10 you are back to using implicit sync.

    The reality here you arguement is over and over again with explicit sync based on ideas that are not fact.
    Last edited by oiaohm; 28 May 2022, 06:47 AM.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by Artim View Post

    Sure, because in real life use cases you will never have anything else than a program that already works around X and Wayland and does its own color management...
    Im a little confused by this statement. we are not talking about color management as a whole. we are talking about HDR support, we have two immensely popular apps that already support HDR, that are widely used on linux it just so happens that neither of them work when used with x11 or wayland compositors because neither have support for HDR.

    is there more needed for other apps to play nice? sure probably so. but regardless all of it needs at least part of the equation. at least we would have at the minimum two very popular applications that will work. and I would argue that most apps should do their own color management if at all possible. well, apps oriented for HDR anyway

    Leave a comment:


  • Artim
    replied
    Originally posted by Quackdoc View Post

    for HDR it's actually one of the big parts, thanks to how wayland is handled with things like direct scan out for fullscreen clients, apps that do their own color management probably don't really need much more than that.

    since an app can use hardware to display their contents, things like MPV and kodi which already support HDR output properly should suffice just sending metadata
    Sure, because in real life use cases you will never have anything else than a program that already works around X and Wayland and does its own color management...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by Artim View Post
    Quackdoc I hope you're joking when you say that by simply adding some protocol magically all compositors can add HDR and color management support. Because obviously that's only the very beginning. Just to be able to be told how things want to look like doesn't magically give you actual color management capabilities. So while wlroots might be the first to include that protocol, rest assured they will be the last ones that can actually handle the content. Or who's supposed to add that?
    for HDR it's actually one of the big parts, thanks to how wayland is handled with things like direct scan out for fullscreen clients, apps that do their own color management probably don't really need much more than that.

    since an app can use hardware to display their contents, things like MPV and kodi which already support HDR output properly should suffice just sending metadata

    Leave a comment:

Working...
X