▲ 83 points
back
15 comments
The headline is misleading. It is indeed KMS support (Kernel Mode Setting), which enables the kernel (and not the graphic driver) to control the display modes. This is better:
1. For boot (no flicker when the graphic driver takes over);
2. For errors (for instance to display kernel errors) and to stay in graphic mode even when X hangs;
3. It enables to run X as an underprivileged user: So it's cleaner and can add security.
It is a new driver, not just KMS support added to the existing one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Ok, we took "with Raspberry Pi Graphics Driver" out of the title.
This appears to be about adding support for Kernel Mode Setting on bcm2835/bcm2836 chips in 4.4
This is probably the relevant commit:
http://cgit.freedesktop.org/~airlied/linux/commit/?id=1f4371...
Sorry but I don't follow this very closely. As a rpi user, what does this mean for me?
Good question, as a fellow rpi user I didn't have the feeling we were lacking a Graphics Driver... Apparently now it is in the Kernel, instead of outside of it. It may just make maintenance of rpi distro's easier as the kernel includes the Graphics Driver there is no need to get it separately.
Pretty sure you were lacking a fully open graphics driver.
The issue with a closed graphics driver is that while it generally works now, it may not work in a few years when the manufacturer decides to stop supporting it.
See for example
Five Years Later, Intel Poulsbo Is Still A Linux Mess
> Pretty sure you were lacking a fully open graphics driver.
Keyword being open.
I suspect most Rpi users just download some IMG-file from the internet, load it up on a SD-card, and run that as is.
Very few will have any involvement with the Rpi hardware at source-code level, or will try to build or tweak their own images.
Does this mean that one of the binary blobs will be gone from the Rpi image now?
EDIT: Ah I see you're saying "is there one fewer blob" not "is there still a blob at all". I don't think that's the case here yet, but perhaps someone more familiar with the driver can comment on whether that will be the case at some point.
As far as I understand it, the Raspberry Pi still needs a binary blob due to the way it boots[0]. The blob is actually loaded into the VPU first before the main processor is even running.
> The most important thing you should know is that the RaspberryPi is a strange beast where the ARM CPU is the not main CPU - it's only a co-processor to the VideoCore GPU. When the RaspberryPi starts, a GPU blob is read from the SD card to the L2 cache and executed. This code then brings up all the important peripherals (RAM, clocks etc) and starts the ARM CPU. Then the 2nd stage bootloader or some operating system itself can be run on ARM CPU.
[0] https://raspberrypi.stackexchange.com/questions/7122/level-o...
"This pull request introduces the vc4 driver, for kernel modesetting on the Raspberry Pi (bcm2835/bcm2836 architectures). It currently supports a display plane and cursor on the HDMI output. The driver doesn't do 3D, power management, or overlay planes yet."
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Full list of changes http://kernelnewbies.org/Linux_4.4
You have to click further to the drivers page [0] and there you find the commit [1].
[0] http://kernelnewbies.org/Linux_4.4-DriversArch [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
I wish there was some way of knowing that the title of the link was before someone decided to change it. Too many times on HN I come across an article and the comments are all talking about something the headline said before it was changed, and I have no idea what the context of the conversation was about.
On a side note, eBPF seems to be the scripting language the kernel would never have, especially with support for compiling programs from C. I wonder why accessing pointers directly is allowed given the verification goals. Why not handles ?