Yeah, that ship has sailed.

I’m not familiar with KDE’s new feature yet, but if it only supports sysfs LEDs then it won’t control 99% of keyboards. Few RGB keyboards have drivers that expose this interface. Most RGB keyboards are controlled from userspace on their official software on Windows, and that’s also what most Linux projects that control RGB devices including my OpenRGB project do. I wonder if it would be possible to write an OpenRGB plugin/script that exposes a virtual /sys/class/leds/openrgb device that KDE could talk to, then translate that into OpenRGB calls to set the color on all available devices. It doesn’t sound too difficult.

It would be nice to see Linux benchmarks for new hardware too. Love GN’s content but I basically ignore his benchmarks as they’re done on Windows. It shows the relative strengths of the hardware but not real world Linux performance.

Native in this case means processor architecture, not OS. The Linux Steam is still x86/x86_64 code and to run it on an ARM system (even running Linux) will require an emulation layer. This adds substantial amounts of overhead, much more than Wine/Proton does for Windows games on Linux.

Same. I started really using Linux with Ubuntu 6.06 and was drawn in by its “Linux for human beings” goals - the Ubuntu homepage of the era really pushed the ideals of community and openness. Canonical sat in the background paying to send you free CDs in the mail. It was such an idealistic thing back then.

And then it all changed around 2010. The color scheme shifted to a shitty MacOS lookalike, the human elements were dropped, the logo was reworked, it got bundled with a paid music store, then Amazon ads in the search, and it’s been a roller coaster on a downward spiral ever since. I switched to Debian not long after the initial enshittification in the early 2010s and have not looked back, though I moved most of my systems to Arch a few years back because I like life in the fast rolling release lane and Debian wouldn’t support my new GPUs.

CentOS good (after they betrayed open source) but Debian bad (even though they remain one of the more independent from corporate influence distros and also serve as the upstream for over half the list)? What even is this nonsense? I agree Ubuntu and its official derivatives maliciously bad and Manjaro completely pointless but that’s about all I agree with.

I wish this were added to the official web UI too. I know they probably have reasons against it but just let us choose for ourselves. They can leave Hot the default but I do think the votes matter and the highest voted comments are usually worth reading.

I would say we’re beyond the era of PC referencing the classic “x86 IBM Personal Computer compatible” definition. PC could reasonably be considered to include many ARM systems, considering there are now Windows laptops shipping with ARM processors that can run “PC” software. Besides, most new x86 PCs aren’t IBM PC compatible anyways as legacy BIOS support has been dropped by a lot of UEFI implementations. I would consider any device that runs a desktop style OS (be it Windows, Linux, or even MacOS) a PC. The distinction in my mind is specifically mobile vs. desktop. Android and iOS are not PC. They’re primarily touch driven and apps are restricted to a certain format with a centralized app store where you are expected to get all of your apps. Windows/Linux/MacOS are primarily keyboard and mouse driven and you have a lot more flexibility on acquiring new apps, with their forms of “sideloading” and “rooting/jailbreaking” being things that are just normal and accepted rather than workarounds/hacks to break out of the walled garden. I would also go as far as saying a smartphone can be a PC if you have a PC like OS on it, such as mobile Linux OSes that let you run desktop applications.

Hopefully more cooperating with than competing against. If NVK is good, Linux users will buy more NVIDIA cards. I don’t see NVIDIA being too opposed to that. Also, if you look at the Mesa merge requests for NVK, there have been a few with @nvidia.com emails. At least a few NVIDIA people are following and contributing even if only very little (one MR I saw was regarding an unknown bit that turned out to be an NVIDIA-internal test environment flag). Also, NVIDIA hired the former nouveau kernel-side maintainer and he just published a large nouveau patch set. I really hope we’re seeing NVIDIA move towards acceptance of the open driver stack even if they continue to develop and push their proprietary one. Given their focus on AI and compute maybe they see letting Mesa handle graphics as less of a concern now. Maybe they want to get everything running on an upstreamable kernelspace driver. Who knows, but it’s definitely looking better than it ever has for them.

Squeekboard is where it’s at. By far my favorite onscreen keyboard for Linux and mainly because you can easily create your own layouts using .yaml files. I’m tired of virtual keyboards that omit keys needed for development and terminal use or shove them off to separate tabs. My custom Squeekboard layout fits my needs exactly and I’m pretty fast at typing on it (typing this on it now). I wish it were usable outside of Phosh, though tbf I haven’t tried. Between GNOME Mobile, KDE Plasma Mobile, and Phosh (Squeekboard), I choose Phosh primarily because of how much I like Squeekboard.

Except that in the case of VGA (and DVI, HDMI, and DisplayPort) the i2c interface is intended for use over the cable. All of those ports have a pair of i2c pins and corresponding wires in their cables. The i2c interface is used for DDC/EDID which is how the computer can identify the capabilities and specifications of the attached display. DDC even provides some rarely-used control functionality. Probably the most useful of which is being able to control the brightness of the display from software. I use the ddcci module on Linux and it lets me control my desktop monitor brightness the same way a laptop would, which is great. I have no idea why this isn’t widely used.

Edit:

This i2c interface is widely used to control the lighting on modern graphics cards that have RGB lighting. We’ve spent a lot of time reverse engineering these chips and their i2c protocols for OpenRGB. GPU chips usually have more i2c buses than the cards have display connectors, so the RGB chip is wired to one of the unused buses. I think AMD GPUs tend to have 8 separate i2c buses but most cards only use 4 or 5 of them for display connectors. There is also an i2c interface present on RAM slots normally used for reading the SPD chip that stores RAM module specifications, timings, etc. This interface is also used for RAM modules with controllable RGB lighting.

Yeah, the lack of proper discoverability on i2c truly sucks. You have to just poke random addresses and hope for the best to see if an i2c device exists on the bus. It’s a great standard but I wish it would get updated with some sort of plug and play autodetection feature. Standardized device PID/VID system like USB and PCI would be acceptable or a standardized register that returns a part string. Anything other than blindly poking registers and hoping you’re not accidentally overvolting the CPU or whatever because the register on your expected device overlaps with the overvolt the CPU register on the same address of a different device.

I use a HYTE CNVS deskpad and a Razer Firefly hard surface mousemat. I’ve found I prefer hard surface mats over cloth ones. I also really like the Razer Mamba Hyperflux, but they don’t make it anymore. It’s a Firefly mouse mat that wirelessly powers the included mouse and it’s a really neat design, though doesn’t work well if your desk has metal supports under where the mousemat goes. For that reason I use it at work, not at my gaming setup.

I mean, the open source driver already is out. The nouveau driver has been in the kernel for like a decade now. The userspace part has been in Mesa for just as long, though largely was unused due to nouveau not being able to use high clock speeds. That isn’t the case anymore, and since the beginning of the year you’ve been able to test drive the new NVK Vulkan driver on nouveau with GSP enabled to get actually reasonable performance in several select games. NVIDIA isn’t creating a new driver, they’re contributing to one that already exists. Since this particular patch set is so huge I don’t know it will make it into the next kernel release right away but this guy was the former nouveau maintainer, I expect he knows the necessary standards to get his code accepted.

I don’t really see why they would hire him to achieve this goal. He had already quit as maintainer. He was out of the picture unless he resigned specifically due to accepting an offer from NVIDIA, but if that was the case and they wanted Nouveau stopped then why is he now contributing a huge patchset? If they hired him and he quit nouveau they could’ve had him work on the proprietary driver or their own open out of tree kernel driver, but they specifically had him (or at least allowed him) to keep working on nouveau.

Also, if they really wanted to EEE nouveau into oblivion, they would need to get every single prominent nouveau, nova, and NVK developer on payroll simultaneously before they silence them all because once one gets silenced why would any of the others even consider an NVIDIA offer? Especially those already employed at Red Hat? It doesn’t really make sense to me as an EEE tactic.

What has been apparent over the past few years is that NVIDIA seems to be relaxing their iron grip on their hardware. They were the only ones who could enable reclocking in such a way that it would be available to a theoretical open source driver and they did exactly that. They moved the functionality they wanted to keep hidden into firmware. They had to have known that doing this would enable nouveau to use it too.

Also, they’re hopping on this bandwagon now that NVK is showing promise of being a truly viable gaming and general purpose use driver. Looking at the AMD side of things, they did the same thing back when they first started supporting Mesa directly. They released some documentation, let the community get a minimally viable driver working, and then poured official resources into making it better. I believe the same situation happened with the Freedreno driver, with Qualcomm eventually contributing patches officially. ARM also announced their support of the Panfrost driver for non-Android Linux use cases only after it had been functionally viable for some time. Maybe it’s a case of “if you can’t beat them, join them” but we’ve seen companies eventually start helping out on open drivers only after dragging their feet for years several times before.

I’m cautiously optimistic. While I could see NVIDIA hiring him to stifle nouveau development, it doesn’t really seem worth it when he already quit as maintainer and Red Hat is already working on nova, a replacement for nouveau. I got into Linux with Ubuntu 6.06 and remember the situation then. NVIDIA and ATI both had proprietary drivers and little open source support, at least for their most recent chipsets of the time. I was planning on building a new PC and going with an NVIDIA card because ATI’s drivers were the hottest of garbage and I had a dreadful experience going from a GeForce 4 MX420 to a Radeon X1600Pro. However, when AMD acquired ATI they released a bunch of documentation. They didn’t immediately start paying people to write FOSS Radeon drivers, but the community (including third party commercial contributors) started writing drivers from these documents. Radeon support quickly got way better. Only after there was a good foundation in place do I remember seeing news about official AMD funded contributors to the Mesa drivers. I hope that’s what we’re now seeing with NVIDIA. They released “documentation” in the form of their open kernel modules for their proprietary userspace as well as reworking features into GSP to make them easier to access, and now that the community supported driver is maturing the see it viable enough to directly contribute to.

I think the same may have happened with Freedreno and Panfrost projects too.

This is my cautious optimism here. I hope they follow this path like the others and not use this to stifle the nouveau project. Besides, stifling one nouveau dev would mean no other nouveau/nova/mesa devs would accept future offers from them. They can’t shut down the open driver at this point, and the GSP changes seem like they purposely enabled this work to begin with. They could’ve just kept the firmware locked down and nouveau would’ve stayed essentially dead indefinitely.

Fuck Riot. Never playing their games again. If you’re going to have a shitty anticheat at least give people the option to play in anticheat disabled lobbies. Besides, they should be doing anticheat at the server level not spying on the boot sequence of client PCs. That shit is unnecessary for a fucking banking app let alone a goddamn game. It’s just a game, let us enjoy it rather than making such a ridiculously over the top response to cheating.

Most of the laptops I’ve seen the external port is connected to the dGPU.

Most gaming laptops these days don’t support true GPU switching as it requires a hardware mux to switch the display between the GPUs. Every gaming laptop I’ve used from the past decade has been muxless and only used render offloading.

I think it’s the other way around. NVIDIA’s marketing name for render offloading (muxless) GPU laptops is NVIDIA Optimus so when the Mesa people were creating the open source version they called it PRIME.