Intel GPU Driver Tries To Rip Out FBDEV Support

[duby229]

Does anyone really use console decorations? And high res is still supported, you just do a straight up DRM console instead of FBDEV console (See KMSCon)

Well, I use fbsplash, but mostly just for the boot splash. Plymouth doesnt work well in gentoo, so fbsplash is the only good alternative.

[Ericg]

It seems to only be in the additions once you install them. not mainline Mesa, or the mainline Linux kernel.

Live CD's won't work on VirtualBox. (or the graphical installers...)

Then we are back to my original point.

[nerdopolis]

VirtualBox gets off its ass and makes a proper KMS driver like VMWare is working on/did

EDIT: Oh hey, guess they are. http://www.phoronix.com/scan.php?pag...tem&px=MTAxOTk Shouldn't be an issue then.

It seems to only be in the additions once you install them. not mainline Mesa, or the mainline Linux kernel.

Live CD's won't work on VirtualBox. (or the graphical installers...)

[MWisBest]

Seems like a daring move, but if it's just a config setting to flip it back on I don't think it's a big deal yet...

[droste]

Currently, no matter how bad the situation, I can switch to the console X was started from, and CTRL-C X. No new processes are started, it's a VT switch to the existing terminal.

Have you ever tried this? Does it work for you that way?
My experience is very different. I could switch eventually, but it was far away from what I would call a reasonable fast response.

[robclark]

And if it's swapped to hell? I doubt it locks all its memory.

@Ericg

Screw your kneejerk reaction. It's not FUD if it's completely true.

If things are in a bad way, I think the only thing you can rely on is switch back to boot console triggerred by the panic notifier in kms, and even that is not necessarily as reliable as you think thanks to a lot of bad locking interactions thanks to the current design of fbdev, notifier_call_chain, console_lock, .. it is really a mess.

Anyways, don't panic yet, I don't think we are quite to the point of disabling fbdev by default. But Daniel has looked a lot into trying to solve some of these locking problems, and I tend to agree with him that we are eventually going to need to rip this all out to fix things properly. Punting it all out to userspace would certainly simplify things in the kernel a lot, which is generally a good thing. A small special process that gets all it's pages pinned could help in the 'swapped to hell' case, for example. There are other things to consider, but current VT switch really isn't the answer. It was designed back in the days of user mode setting, resulting in a bit of a dance between kernel space and userspace. Try attaching gdb to X11 and do a VT switch then :-P

[Ericg]

With KMS, I don't think X has much to say about a VT switch. The kernel can still listen to the keyboard with X completely deadlocked, not once has magic sysrq failed in such a situation for me.

info I found (granted it was a forum thread on linuxquestions-- but it was from 2012, so it was post the switch to KMS) said that the kernel handles going from VT to X, but thag X controlled the X-to-VT handoff.

not saying you're wrong, the thread may have been wrong, but show me some documentation that says otherwise. otherwise we are just having a he-said-she-said debate.

[curaga]

With KMS, I don't think X has much to say about a VT switch. The kernel can still listen to the keyboard with X completely deadlocked, not once has magic sysrq failed in such a situation for me.

[Ericg]

And if it's swapped to hell? I doubt it locks all its memory.

@Ericg

Screw your kneejerk reaction. It's not FUD if it's completely true.

It is one more place to break, when compared to status quo. Currently, no matter how bad the situation, I can switch to the console X was started from, and CTRL-C X. No new processes are started, it's a VT switch to the existing terminal.

If the VT switch were relegated to userspace like with kmscon, it could take minutes longer, if it succeeded at all.

Not a kneejerk reaction, people shouting that the VT is in kernelspace annoys me as much as the people shouting that "Wayland can't do networking!!" Because its completely false.

Nothing that matters in the VT is in kernelspace. Switching from X to a VT1 is handled by X, so if X is completely deadlocked then you cant even switch out, switching from VT1 to X is handled by Kernelspace.

I'm not saying you can't have legitimate reasons against Kmscon, but the ones you are saying aren't them.. Everything ALREADY is in userspace.

[curaga]

And if it's swapped to hell? I doubt it locks all its memory.

@Ericg

Screw your kneejerk reaction. It's not FUD if it's completely true.

It is one more place to break, when compared to status quo. Currently, no matter how bad the situation, I can switch to the console X was started from, and CTRL-C X. No new processes are started, it's a VT switch to the existing terminal.

If the VT switch were relegated to userspace like with kmscon, it could take minutes longer, if it succeeded at all.