0·
1 year agobecause lemmy is bad
Quack Doc
- 0 Posts
- 23 Comments
Joined 3 years ago
Cake day: July 20th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
it’s not clear at all what he means.
I am not sure I understand what this has to do with the article. Also, I don’t see why that would be the case. I don’t see much of a good reason to lock the VMs down.
Im not sure what you mean, like, run android on mainline linux? if that is the case you already can. Not on all devices, but I think the pixel can run mainline kernel, I know ofc you can run androidx86 on mainline, if you mean via terminal I think you can sideload mainline. At least, if you compile your own rom you absolutely would be able to.
Assuming that all monitors do anything specific at all would be a folly, no. There are no assumptions there, the sRGB spec has no ambiguity when it comes to the transfer function of the display.
That a certain percentage of displays don’t behave like expected is annoying, but doesn’t really change anything (beyond allowing the user to change the assumed transfer function in SDR mode).
the video https://www.youtube.com/watch?v=NzhUzeNUBuM goes more indepth, but it’s a very true statement to say that “some displays decode with the inverse oetf and some don’t” this issue has been plaguing displays for decades now.
There are no assumptions there, the sRGB spec has no ambiguity when it comes to the transfer function of the display.
You are 100% right in saying “the reference display is gamma 2.2” however, we can only wish this is what displays do, Color.org themselves got this wrong!!! https://www.color.org/srgb.pdf and leads people astray.
The most likely actual reason Window uses the piece-wise transfer function for HDR is that it did that in SDR mode too - where however the default ICC profile was also piece-wise sRGB, so it canceled out on 99% of PCs, and had no negative effects.
I don’t actually believe this to be the case, if it was people who use custom ICCs would get extremely wonky results that don’t typically happen. On the other hand it is very true that colors when doing it the way they do, you get the “least offensive” results. Though IMO the best solution would be to simply be to default to the pure 2.2 and allow users to override the transfer. the Color protocol allows for explicit peicewise sRGB anyways, so doing this should fit right into a fleshed out colormanaged setup.
That’s a very different thing. Pushing viewing environment adjustments to the display side makes some amount of sense with SDR monitors - when you get an SDR display with increased luminance capabilities vs. the old one, you change the monitor to display the content comfortably in your environment
I think I am a bit confused on the laptop analogy then, could you elaborate on it?
With HDR though, if the operating system considers PQ content to be absolute in luminance, you can’t properly adjust that on the monitor side anymore, because a lot of monitors completely lock you out of brightness controls in HDR mode, and the vast majority of the ones that do allow you to adjust it, only allow you to reduce luminance, not increase it above “PQ absolute”.
How monitors typically handle this is beyond me I will admit, But I have seen some really bonkers ways of handling it so I couldn’t really comment on whether or not this holds true one way or another. Just so I am not misinterpeting you, are you saying that “if you feed 300nits of PQ, the monitor will not allow it to go above it’s 300nits”? IF so this is not the case on what happens on my TV unless I am in “creator/PC” mode. In other modes it will allow it to go brighter or dimmer.
My current monitor is only a 380nit display so I can’t really verify on that (nor do I have the hardware to atm)
I didn’t claim that PQ had only one specification that uses it, I split up SMPTE ST 2084, rec.2100 and BT.2408 for a reason. I didn’t dive into it further because a hundred pages of diving into every detail that’s irrelevant in practice is counter productive to people actually learning useful things.
ah I see, I was a bit confused on what you had meant then. My apologies.
Can you expand on what you mean with that?
Keep in mind this was based on the above misinterpretation of what I thought you meant.
With libjxl it doesn’t really default to the “SDR white == 203” reference from the “reference white == SDR white” common… choice? not sure how to word it… Anyways, libjxl defaults to “SDR white = 255” or something along those lines, I can’t quite remember. The reasoning for this was simple, that was what they were tuning butteraugli on.
That “directly” is very important, as it does very much make both these signal levels the same. As I wrote in the blog post, the spec is all about broadcasts and video.
Other systems do sometimes split these two things up, but that nearly always just results in a bad user experience. I won’t rant anymore about the crapshow that is HDR on Windows, but my LG TV cranks up brightness of its UI to the absolute maximum while an HDR video is playing. If they would adhere to the recommendations of BT.2408, they would work much better.
I think this is an issue of terminology and stuff, reference white is something the colourist often decides. When you assume that HDR graphics white == SDR white this actually causes more problems then it solves. I would say that it is a “good default”, but not a safe value to assume. This is something the user may often need to override. I know personally even when just watching movies on MPV this is something I very often need to play with to get a good experience, and this is not even counting professionally done work.
That’s just absolute nonsense. The very very vast majority of users do not have any clue whatsoever what transfer function content is using, or even what a transfer function, buffer encoding or even buffers are, the only difference they can see is that HDR gets brighter than SDR.
And again, this too is about how applications should use the Wayland protocol. This is the only way to define it that makes any sense.
this actually isn’t really that true. It is indeed the case that users wont know what transfer function content is using. but they absolutely do see a difference other then “HDR gets brighter then SDR” and that is “it’s more smooth in the dark areas” because that is also equally true.
Users have a lot of different assumptions about HDR, but they all follow some sort of trend “it makes the content look more smooth at a greater range of luminance” and if I were to give a “technical definition that follows general user expectations” the definition would be something along the lines of “A transfer that provides perceptually smooth steps of luminance at a given bit depth up to at least 1000 nits in a given reference environment” which is bad for sure, but at the very least, it more closely aligns with general expectations of HDR given it’s use in marketing.
(I really hate the terms HDR and SDR btw, I wish they would die in a fire for any technical discussion and really wish we could dissuade people from using the term)
I should elaborate on why the “Peak white” stuff is wrong, they give this math here for mapping linear luminance. This can be really confusing, “what do we map the references to” well if PQ “graphics white” is 203, should we map sRGB to 203? clearly not, at least not always as implied by BT.2408.
the question as to what we map SDR content to in an HDR space is complex, and in many cases almost certainly not some number that we can do 1:1 mapping with, which is why specifications for inverse tonemapping exist. for instance BT.2446 defines multiple tone mapping algorithms to go from SDR->HDR->SDR or HDR->SDR->HDR or any step inbetween with minimal content loss and fidelity loss.
we cannot do a simple one size fits all function and expect everything to be hunky dory
This makes a numerous amounts of incorrect assumptions.
For one it assumes all sRGB monitors utilize gamma2.2 for decoding images. This is bluntly put, completely wrong. A large amount of displays utilize the inverse OETF (the peicewise srgb transform) for decoding sRGB. (for some more information from a somewhat authoritative body, filmlight’s “srgb we need to talk” video on youtube goes more indepth but TLDR is 25-50% of displays use the inverse sRGB oetf)
this is why windows HDR uses the inverse oetf. Decoding content graded on a pure 2.2 display with the inverse oetf is way better then decoding content graded on an inverse oetf display with a pure 2.2. Windows took the safe route of making sure most content looks at least OK. I would not say that windows HDR is wrong, it’s not right, but it’s not wrong either. this is just the mess that sRGB gave us.
Another time you should be using the inverse sRGB OETF to linearize content when the original content was encoded using the sRGB oetf and you want to go back to that working data, but this applies less to compositors and more to authoring workflows.
Another wrong assumption
When you use Windows 11 on a desktop monitor and enable HDR, you get an “SDR content brightness” slider in the settings - treating HDR content as something completely separate that’s somehow independent of the viewing environment, and that you cannot adjust the brightness of. With laptop displays however, you get a normal brightness slider, which applies to both SDR and HDR content.
People have been adjusting monitor brightness for ages. Sometimes manually, sometimes with DDC etc.
Another issue that is brought up is “graphics white” BT.2408 is a suggestion, not a hard coded spec, many different specs or suggestions use a different “graphics white” value. A good example of this is JXL. 2408 also very explicitly says ‘The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.’
this is important to note because this directly contradicts the some of the seemingly core assumptions made in the article, and even some of the bullet points like “a reference luminance, also known as HDR reference white, graphics white or SDR white” and “SDR things, like user interfaces in games, should use the reference luminance too”
if your application has some need to differentiate between “SDR” and “HDR” displays (to change the buffer format for example), you can do so by checking if the maximum mastering luminance is greater than the reference luminance
This needs to be expanded upon that this does NOT correlate to what the general user understands HDR and SDR to be. HDR and SDR in the terms of video content is no more then a marketing term and without context it can be hard to define what it is, However it is abundantly clear from this quote here that how they are interpreting HDR and SDR (which is a very valid technically inclined way of interpreting it) does NOT fall inline with general user expectation.
Anyone reading this article should be made aware of this.
way more simple to use and maintain for users. aerynos behaves almost exactly like a traditional distro with the exception of the /usr stuff
aerynos is pretty much just another distro as far as the user is concerned. extremely user/normie friendly unlike nix, and unlike fedora silverblue it doesn’t have a bunch of dumb limitations like forcing the user to use containers.
0·2 years agoAndroid has done a lot of great desktop windowing work. For a while stuff like boringdroid has been great, its supurbe to see android accept this kind of usage more.
for me I just really like the competition. I personally have a strong distaste for both chromium and firefox. Really hoping servo and ladybird become strong contenders quickly, servo is actually looking really strong now with it’s speed and compat, but ill take what I can
I still couldnt see myself using kagi or really any webkit browser, but hey, I will at least give it a try
0·2 years agoI wish ludusavi could handle game mods too, as a lot of games I play use mods (like stardew). Mods are essential for the saves there
0·2 years agoI want a phone that stops falling out of my hands man…
this is not true. SO many people will download and install whatever. I still get my old customers calling me up for help because they installed some registry cleaners promising to increase their performance by 5x
As someone who used to sell computers to elderly and people who are generally non tech literate, as well as ran computer literacy courses;
ChromeOS + something like flatpak. I don’t think anything else will really work in the current linux world. Holding on hope for Cosmic based DE.
A Distro must have
- Easy AND reliable DE. KDE has been way too buggy and gnome has been way too hard for my parents to use. Old people often have an extremely hard time learning, it needs to replicate what they already know which is either going to be Windows or OSX most likely. Cosmic should be able to do both nicely when ready.
Reliability is so fucking key here I can not understate it. The computer glitching out is entirely unacceptable. They will not be able to do any debugging nor will you likely be on call 24/7 to fix their issues. They also need security so you can’t just “set and forget” either with no updates in a false sense of stability. Older folk copy and paste shit. Permissions and stability is key here. Flatpak has a lot of potential but it’s not there yet.
No real time AV really hurts here.
-
Extremely strong app selection with either android or wine app support. Wine is the most preferable. A lot of people are reliant on windows programs for things like tax filing and all sorts of stuff like crochet software and what not. Android apps however can often be good enough and are extremely simple so with a little help, and you will need to help, they can get by with android app support.
-
A11y, screenreaders, OSKs, maginifers etc. We need all of it if we want to fit the “generic elderly support”
-
Good performance. Elderly people do NOT like updating systems, Their systems will likely be old. And well they are old too. If a system is slower then what they are used to, and generally non responsive, they may think the bloody thing is broken.
cough cough gnome cough cough
I genuinely do not that that any DE let alone distro is an acceptable daily driver for “general people” because general people have such a wide variety of use cases and needs. Some folk need crochet and tax software, some folk need CNC software like stitchfiddle, Some need magnifier glasses and speech to text. and man, this is only the more common of things i’ve seen.
Remeber folk, a PC that does 99% of what people generally need, does not mean that it will fit the needs of 99% of people. Here is hoping to a bright future, but I don’t think it will be a close one.
Click baity title aside. This is actually pretty much pretty true. What the vast majority of people want when they’re writing their own composers seems to be specifically the custom window management aspects.
And it is true that even with something like Wlroots or a Smithay, it is a lot of works right your own composer and have it be “competitive”. And he is right. There are a lot of composers out there that are just not usable for anything more than the basics. And there are tons more which are just toys that have been abandoned that aren’t really usable. That being said we saw a lot of that with window managers, But yes, writing a compositor is a lot more then writing a window manager.
I personally don’t use hyperland, but I can see the point he’s trying to make, and I think it’s a rather good point. I think if we had more compositors that focused on having a scriptable window management, then that would be for the better.
I don’t really see this as toxic either. I mean, if it’s toxic to call a composite or trash in one way or another, then I would argue that 90% of the Linux community is far more toxic than he is. It’s just a matter of truth. Wayland is a big complicated thing with a lot of protocols and some of it is poorly documented.
And of course, this is him shilling his own composter. It’s his own composter, and this is the blog about him making his own composter. Of course he’s gonna put a post on it, shilling his own compositor.
That being said, As I said earlier, I would like to see a more scriptable take for things like window management. I don’t think hyprland has to be unique in this aspect, but as it stands, it most definitely is.
pardon my weird language, its hard to use STT.
Chroot = change root, and needs root to do so. Doing anything as root is insecure. escaping a chroot really isn’t all that hard. The second you elevate privledges, you need extra steps to to become secure. Chroot almost never involves any of these steps (though there is some selinux stuff you could do.)
This is an old example, but still a valid one https://github.com/earthquake/chw00t
Termux has been a thing for years.
Termux is not a full linux environment, you need proot (slow) or chroot (insecure) to get a full environment.
A few things,
there are other issues I have but these are the ones off the top of my head. It’s simply a far inferior experience to reddit.