Vik

The graphene community in the past has pointed out Firefox’s incomplete content sandboxing implementation and suggested that other aspects of security are not up to chromiums standard. They pointed out other technical shortcomings as well, though I can’t recall them, I’m not sure how urgent they’d be.

This was several years ago, and I’m not sure if any of this has been addressed, but I wouldn’t like to rely on manifest v3 compliant ad blocking.

I get the impression that Firefox may continue to lag in this regard, and I don’t feel that people like us are made vulnerable by this, though I do worry about people like my parents.

One of the comments on the phoronix post mention display stream compression (DSC) and fixed rate link (FRL - specific to HDMI 2.1), both assist with high bandwidth throughput.

No but I do get about three or four challenges. I can paste the article for you if it helps?

archive link

https://archive.is/N4thi

at this rate, couldn’t they just sunset their client and contribute towards heroic?

excellent find! hope it serves you well

nvidia have been promoting ‘big format gaming displays’ since I want to say about 2019. Some of them reach the dimensions you specify, I just hope these are VESA adaptive sync/FreeSync capable and not all GSync Ultimate module displays (they can be made to work in VESA mode but not without issues in my experience).

I think I’ve seen one or two obscure TV models offering DisplayPort over USB type C, it may have been from Hisense

No prob, really sorry about the situation though, I know it sucks. I’ve been looking into replacing my TVs with large PC displays with DisplayPort.

I’m not sure if you can somehow work around the HDMI forum limitation with an active converter, but I think they’re intended to be used at the adapter side (convert HDMI output to DP).

You don’t need proprietary drivers nor should you have to disable MST.

If you’re using HDMI 2.1, you won’t be able to use VRR on a Linux system as the HDMI forum have blocked the AMDGPU implementation for the feature - they don’t allow FOSS implementations of HDMI 2.1 VRR

More info here https://wiki.archlinux.org/title/Variable_refresh_rate

Thanks for these, I’ll discuss with the DAL team when I get the chance

Oh sorry, I misunderstood, so you actually get locked into a low mclk under specific display configurations? I’ve genuinely never heard of or personally experienced that across a breadth of hw and sw configs.

I’m wondering if it could be worth probing the power play sysfs interface or hwmon the next time this happens to try and understand what’s happening there.

Do you use client apps to interact with tuning settings like LACT? Can you link me to an existing bug report so I can follow up with engineering?

Can you elaborate on your display config?

You kind of alluded to part of it there; it’s not so much a bug in sw/fw as it is a hardware limitation at both the adapter and display side. The variables for displays are vertical blanking intervals (and differences between panels), as well as total display bandwidth.

with RDNA2, a feature was implemented in DAL to leverage VRR in order to allow a single connected display system to achieve a lower mclk, and thus lower idle power draw. With RDNA3, hardware changes (MALL specifically) broadened this capability two concurrent displays. Even then, it’s not bulletproof.

The display eng team has more or less exhaustively worked towards this over the course of RDNA3’s lifespan; their work is applicable to both Windows and Linux.

Do you have an OSD for active refresh rate built into your displays? FreeSync / VRR can be managed directly by your DE settings

I think you went from a 25.10 branch at a point where the KMD split had already occurred. This means that support for kmd3 devices (RDNA3+4) was not present, which lead to the abject chaos you saw on windows

I’m curious about the network remark though. Was this on windows 10 or 11? Can you tell me which platform (motherboard chipset) this is with?

no it’s fine, I thought you had the inside scoop there for a sec 😅 I’m sure we’ll see an android build eventually.

either way, I think we’re pretty well served for Firefox forks across desktop and mobile

nah just the OP was asking for android specifically

Is there a mobile version for this yet?

Fennec on fdroid perhaps?

this cave is not a natural formation

Iirc, the free version of resolve lacks hw accel via OpenCL on Linux for specific formats like MP4. What are your encode settings? If you pay for resolve, I would try contacting the vendor. I’m not sure if the app supports ROCm / HIP directly (I gather it does but haven’t used this path directly), but you can try installing the ROCm meta package via dnf on Fedora Workstation (or rpm-ostree package overlay on Bazzite) to see if that opens up more options.

I’ll check in with OBS later to confirm my settings.

I’m not sure how it is for atomic apps but if video players like VLC and MPV are complaining, you may need to grab the gstreamer plugins from the store? (I need to check if this is consistent across fedora workstation and immutable setups like on my fedora silverblue install)