Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Gets Kernel-Based Modesetting

Posted by timothy on from the always-wanted-a-linux-bsod dept.

An anonymous reader writes "Next month when Fedora 9 is released it will be the first Linux distribution with support for kernel mode-setting, which is (surprisingly) a feature end-users should take note over. Kernel-based modesetting provides a flicker-free boot process, faster and more reliable VT switching, a Linux BSOD, and of most interest is much-improved suspend/resume support! The process of moving the modesetting code from the X.Org video driver into the Linux kernel isn't easy, but it should become official with the Linux 2.6.27 kernel, and the Intel video driver can already use this technology. Phoronix has a preview of kernel-based modesetting covering more of this new Linux feature accompanied by videos showing the dramatic improvements in virtual terminal switching."

59 of 81 comments (clear)

  1. Re:Hasn't this been settled ? by Anonymous Coward · · Score: 1, Funny

    Clearly Tanenbaum was right, since OS X has a microkernal.

    BSD is dead. Netcraft has confirmed it. Therefore, OS X is dead.

  2. Oh boy! by Malevolyn · · Score: 5, Funny

    Just what we need: a Linux BSOD!

    --
    Your ad here.
    1. Re:Oh boy! by PenisLands · · Score: 3, Interesting

      Indeed. It would be nice to actually have some helpful error messages so users can work out what on earth has gone wrong.

    2. Re:Oh boy! by HTRednek · · Score: 1

      BSOD?!? So what happened? All the underpaid Micro$haft coders decide to play with Linux? The next thing you'll see is all Linux apps starting with i... iKonqueror, emac.. err imacs, even ililo? If I ever see Tux in a rainbow jacket munchin' an apple, I quit!

    3. Re:Oh boy! by mrmeval · · Score: 1

      Yea what moron wanted that?

      --
      I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
    4. Re:Oh boy! by jcast · · Score: 1

      No, no, no. All Linux apps start with g!

      --
      There are reasons why democracy does not work nearly as well as capitalism.
      -- David D. Friedman
    5. Re:Oh boy! by Wiseman1024 · · Score: 1

      That's the GNAAome ones. The KDE ones start with a K.

      --
      I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
    6. Re:Oh boy! by JohnBailey · · Score: 1

      Just what we need: a Linux BSOD! But we have for ages. System>Preferences>Look and feel>Screensavers...
      --
      It is difficult to get a man to understand something when his job depends on not understanding it.
    7. Re:Oh boy! by paulatz · · Score: 1

      I remember the old days, when they all started with x

      --
      this post contain no useful information, no need to mod it down
  3. Waitasec... by jamstar7 · · Score: 5, Funny

    A BSOD? Lemme guess, that patch came from Novell, right?

    --
    Understanding the scope of the problem is the first step on the path to true panic.
    1. Re:Waitasec... by Dolda2000 · · Score: 1

      Funny as you may have been, I for one am looking forward to the BSOD patch. It would be quite helpful to actually be able to see a panic message even though an X server is running. Not that I'm encountering more than one every two years or so, but nonetheless.

  4. KGI, only much later and missing some features. by Bloater · · Score: 4, Informative

    It's about time, KGI was a patch to Linux many many years ago to enhance Linux graphics support just like combining this kernel modesetting with DRI (except that KGI had decent security measures designed in right from the start).

    As usual the old guard says something like "Graphics isn't relevant" and holds back progress for years on end.

    1. Re:KGI, only much later and missing some features. by jd · · Score: 4, Insightful
      KGI was a damn good system - somewhat overshaddowed by GGI and other similar efforts, though, as the argument of the time was that the kernel shouldn't do what userspace can do. KGI might have stood a better chance if development had been faster, or some significant card could not be made to work correctly in userspace, or there was a demonstrable vulnerability implied.

      As I recall, there was also the arument that grahics in the kernel risked instability that would impact the system and be hard to trace. I can sympathize with this argument a bit more, but in the end it is true of all hardware drivers - hence the efforts of microkernel and exokernel developers to move such stuff into isolatable containers. It's a good idea, not terribly efficient because of all the message passing, but I can understand the reasoning.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    2. Re:KGI, only much later and missing some features. by techno-vampire · · Score: 3, Insightful
      As I recall, there was also the arument that grahics in the kernel risked instability that would impact the system...


      How true that is! I once worked at a shop where everybody was on NT4, and my box kept blue-screening because of a bug in the graphics driver. Putting drivers like that in kernel space just to get a little more speed is downright stupid, especially when you consider that NT 4 was largely marketed as a server OS where graphics weren't exactly important. I can't help but feel, given my experience, that this isn't exactly the best of ideas.

      --
      Good, inexpensive web hosting
    3. Re:KGI, only much later and missing some features. by Bloater · · Score: 4, Informative

      KGI never put graphics into the kernel, it only put mode setting into the kernel and provided a means to communicate with graphics hardware other than dumb MMIO to userspace. Individual drivers could do graphics in the kernel, but most cards could do either dump mapping if it is secure, or userspace could fill a buffer with a list of writes to be done and the driver would check them for safety and then just perform the described writes. Most of the cards that would need a full kernel graphics driver were slower than software rendering.

    4. Re:KGI, only much later and missing some features. by techno-vampire · · Score: 1

      Thank you. I'm a software geek, not hardware, but I'm not into systems programming, more luser support. I pick things up, here and there that are useful, but I'd never claim to know everything. Live and learn, that's my motto!

      --
      Good, inexpensive web hosting
    5. Re:KGI, only much later and missing some features. by RiotingPacifist · · Score: 2, Funny

      woot in 2018 well get rieser4 :D

      --
      IranAir Flight 655 never forget!
    6. Re:KGI, only much later and missing some features. by RAMMS+EIN · · Score: 3, Insightful

      ``KGI was a damn good system - somewhat overshaddowed by GGI and other similar efforts, though, as the argument of the time was that the kernel shouldn't do what userspace can do.''

      There is a point to that. On the other hand, it is questionable whether, in Linux, userspace _should_ be able to do all the things needed to drive the graphics card. Userspace directly accessing hardware and reading and writing arbitrary memory locations?

      On the gripping hand, the reason this is unsafe is only that the languages we use are unsafe. They don't gurantee that processes don't access things that aren't theirs. Essentially, we solve this by imposing a sort of dynamic type checking: we run these unsafe processes in a restricted mode, where the hardware limits their access to memory and I/O ports. Of course, sometimes, you _do_ need more than this restricted access, and that's what the kernel does. We trust the kernel to do it right. But now we've used indirection into the process: to access the hardware, a process needs to go through the kernel, which (hopefully) restricts the process to only doing benign things to the hardware. This is, of course, slower than it could be. Especially on x86, where switching from user mode to kernel mode is quite an expensive operation. This is the real reason why microkernels are slow.

      An alternative would be to have the compiler perform or insert the checks that, in current systems, are performed by the kernel and the hardware at run-time. This way, processes don't have to run in restricted mode and go through the kernel anymore, because they aren't going to do any of the things the kernel would prevent them from doing anyway. Of course, this requires a rather safer type system than C's, and it shifts trust from the kernel to the compiler - which raises issues about how you can know that the code you want to run was indeed compiled by a trustworthy compiler. However, these issues can be solved, and you end up with a system that can be more modular _and_ more efficient.

      --
      Please correct me if I got my facts wrong.
    7. Re:KGI, only much later and missing some features. by Kjella · · Score: 3, Insightful

      as the argument of the time was that the kernel shouldn't do what userspace can do. Well, from what I can read out of the description this has absolutely zero benefits for servers so I figure the discussion in 1998 went a little differently. KDE 1.0 was released in july 1998 and Gnome 1.0 wasn't out either, and things like "smooth graphical booting process" probably wasn't a major issue to say the least. There's always a balance between creating layers and hindering features, like for example ZFS which breaks the traditional file system model. At the time, I think it was probably right for Linux as they had more important things to focus on.
      --
      Live today, because you never know what tomorrow brings
    8. Re:KGI, only much later and missing some features. by jd · · Score: 1

      It doesn't help that GCC 4.2.x is getting a bad rap for potentially optimizing out some bounds-checking. A third option would be to require three rings, rather than two, and have the third ring perform potentially hazardous (to the OS) operations. This would require much faster context switching and better communications. Or maybe not. If you have a 4 core CPU and dedicate 1 core to the kernel, 1 core to hazardous operations, and leave the other 2 open to the user, you have no context switches, you only have message passing between cores.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    9. Re:KGI, only much later and missing some features. by tepples · · Score: 1

      Userspace directly accessing hardware and reading and writing arbitrary memory locations? They're not so arbitrary. The kernel lets a display server process mmap two specific parts of memory, namely VRAM and the I/O registers. How is it any different from implementing a file system in user space?

      Of course, this requires a rather safer type system than C's, and it shifts trust from the kernel to the compiler - which raises issues about how you can know that the code you want to run was indeed compiled by a trustworthy compiler. Unfortunately, the common way to do this is to require that all code executing on a system be signed by the system's manufacturer. This is the case for TiVo, iPhone, and all video game consoles other than the HTPC, and such manufacturers tend to require contractual terms that shut out hobbyist developers.
    10. Re:KGI, only much later and missing some features. by ThePhilips · · Score: 2, Insightful

      [...] the reason this is unsafe is only that the languages we use are unsafe.

      Yeeees. Right. Absolutely.

      This has nothing to do with sloppy programming and bunch of incompetent monkeys who managed to get to keyboard because it is cool.

      The difference between good developer and bad developer is that good developer always listens to user feed back. To system developers that's application developers are users. To application developers that's end-users are users. To hardware developers that's system developers are users.

      NT4 in that respect set all time record for shittiest programming ever. M$ with Win2k/WinXP/Vista was doing essentially one thing: making system simpler, system which wouldn't drive developers insane.

      Most of previous Linux attempts to moving parts of graphics into kernel were hindered in some part by lack of documentation and most importantly oversized ego of some developers calling for revolution. But in fact there were no revolution and nothing extraordinary new was done: people were trying to randomly move stuff around kernel/user space, nothing more. GGI was classical example: you could do the same with X - but it wasn't ever tried nor done. Because its developers were dead set on changing everything - no compromises allowed. For sake of highly experimental project recrafting stable kernel interfaces? That will never happen. The fact now that most of the mod setting development is done under hood of X.Org is a sign that it is going to be done right - because it is going to be done using stable ground, not shaking foundation of highly experimental library.

      --
      All hope abandon ye who enter here.
    11. Re:KGI, only much later and missing some features. by Bloater · · Score: 2, Informative

      "They" (one group of kernel devs) didn't have more important things to work on than security in the face of 3d accelerated application support - which is why that group of kernel devs wrote KGI.

      Unfortunately "They" (a larger group of kernel devs who only switched out of EGA mode for multiple terminals on one screen, a group that seems to have included Linus Torvalds) thought that companies who were paid to provide realtime 3d rendered displays of data/media for whatever reasons (eg medical visualisation, pilot training, etc), didn't deserve to have security.

      I'm not joking, they actually said people who use 3d don't need secure computers and should not be provided with both 3d and security at the expense of running 3d rendering algorithms in ring 0. Even though no KGI drivers did that, at most (a couple of drivers) they fiddled a few words on the card to shift data precalculated in user space onto the card.

      This was all because the second, larger, "They" thought that 3D meant "movie rendering" where the networks were already highly secure or "games" where it is only a child's computer and the family didn't share it for internet banking, etc - and nor should they ("Damned families, not giving their children a dedicated computer, they ought to be locked up").

      Crazy

    12. Re:KGI, only much later and missing some features. by Excors · · Score: 1

      An alternative would be to have the compiler perform or insert the checks that, in current systems, are performed by the kernel and the hardware at run-time. This way, processes don't have to run in restricted mode and go through the kernel anymore, because they aren't going to do any of the things the kernel would prevent them from doing anyway. Of course, this requires a rather safer type system than C's, and it shifts trust from the kernel to the compiler - which raises issues about how you can know that the code you want to run was indeed compiled by a trustworthy compiler.

      You can do this without a trusted compiler – when an untrusted compiler compiles a program, it can work out how to prove that the program is 'correct' (e.g. follows the restrictions on memory accesses, perhaps by first having the compiler insert "if memory access if out of range: abort" commands before every access it's unsure about), and then include the proof in the compiled code. The kernel just has to verify that the proof is valid, which is much easier than working out the proof in the first place. If the compiler lies about code being correct, the verifier will detect that and refuse to run it.

      The compiler can accept an unsafe language like C, and just emit an error message (and hopefully tell the user where the problem is) if it's unable to prove the program is correct. It wouldn't be possible to run any arbitrary C program, but it wouldn't be necessary to teach people a whole new language.

      Of course this is all active research, i.e. it doesn't actually work well enough in practice (and maybe it never will), but it's still an alternative that could work and avoids any reliance on trusted compilers.

    13. Re:KGI, only much later and missing some features. by GreyWolf3000 · · Score: 1

      Run time dynamic "type checking" versus a user mode to kernel mode context switch...I think there are probably ways to speed graphics up without ripping out the MMU and designing a new language to write the operating system in. You could, for example, use a soft real time scheduler, and guarantee that the process writing to mmio()'ed video memory be executed before refresh with enough time to actually write out. If your scheduling is good enough you can do away with the context switch altogether and just rely on a futex that the graphics driver in user space shares with the kernel code. Triple or more buffering can ensure that occasional hiccups in scheduling don't cause tears.

      --
      Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
    14. Re:KGI, only much later and missing some features. by Bert64 · · Score: 1

      And how many NT4 "servers" were sat permanently displaying one of the crappy built in opengl screensavers and using 100% cpu to do it?

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  5. Re:Thanks but no thanks by Malevolyn · · Score: 1

    Forget it, dude. you can write your own drivers.

    Couldn't resist.

    --
    Your ad here.
  6. Confirmed, works and is very promising by Enleth · · Score: 4, Interesting

    I've been trying it out since it became usable at all in the relevant git trees, with Intel driver of course - and it works wonders. Probably one of the best inventions after sliced bread. Well, seriously, it will definitely help the authors of graphics drivers, providing a unified framework for all modesetting kludges and simplify the actual drivers, especially direct rendering. AFAIK all the new Radeon drivers (those made with the specifications AMD released) will be using it, as well as DRI2, so not only Intel GMA users will benefit very soon.

    --
    This is Slashdot. Common sense is futile. You will be modded down.
    1. Re:Confirmed, works and is very promising by JackieBrown · · Score: 2, Funny

      I wish I hadn't just bought a nvidia card.

      Being a Linux user, I never thought I'd say that.

    2. Re:Confirmed, works and is very promising by makomk · · Score: 1

      Nouveau (the reverse engineered open source driver) is making nice progress with pre-8000 series GeForce cards, and I think they're planning to eventually move to kernel modesetting. Of course, you don't get 3D support, and support for 8000-series and up still isn't in a usable state.

      This is all no thanks to NVidia, who haven't released any sort of specs (not even for modesetting, which they can't easily argue would help their competitors or reveal any big secrets).

  7. Re:Thanks but no thanks by sticks_us · · Score: 3, Informative

    I've tried contributing code, but they're stuck in a cathedral and won't acknowledge me.

    I hear ya...I've better luck with the Debian Hurd project, give them a shot:

    http://www.debian.org/ports/hurd/

    If it's been a while, you might be pleasantly surprised: you can get a decent GNU/Hurd install going without too much trouble, there are things happening, development-wise (including possible "summer of code" participation) and so on.

    Good luck.

    --
    "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
  8. Cross platform X compatibility? by jensend · · Score: 4, Interesting

    Does anybody have some insights on how this will affect those not using Linux kernels with this patch?
    Are the *BSDs and commercial Unices planning on similar work? Will support for modesetting eventually be dropped from X drivers?

    1. Re:Cross platform X compatibility? by michaelmuffin · · Score: 2, Informative

      Does anybody have some insights on how this will affect those not using Linux kernels with this patch?
      Are the *BSDs and commercial Unices planning on similar work? Will support for modesetting eventually be dropped from X drivers? I was under the impression that Solaris already did this, to name one. solaris has its own x11 implementation -- http://en.wikipedia.org/wiki/Xsun -- although x.org is an option for the i386 platform
  9. Is this the least commented on story ever ? by Anonymous Coward · · Score: 1, Insightful

    If not, what is the least commented on story of all time ? Maybe starting at 1999.

  10. Re:What for? by Anonymous Coward · · Score: 1, Informative

    What's the justification for moving modesetting into kernel space?

    The justification is, if the X server crashes, the kernel can restore the display to a usable state. It also ensures that the display is reinitialized properly after suspend/resume.
  11. Re:Thanks but no thanks by Goalie_Ca · · Score: 2, Funny

    If I had a lot of money like google does then I would fund just enough work to keep the joke alive :D

    --

    ----
    Go canucks, habs, and sens!
  12. Re:Hasn't this been settled ? by calebt3 · · Score: 1

    Nah, it said BSD was dying. In the sense that everything is always dying.

  13. Re:Hasn't this been settled ? by laffer1 · · Score: 2, Insightful

    Apple uses a hybrid kernel called XNU actually. http://en.wikipedia.org/wiki/XNU

    --
    MidnightBSD: The BSD for Everyone
  14. Re:Thanks but no thanks by Kjella · · Score: 1

    I hear ya...I've better luck with the Debian Hurd project, give them a shot: Translation: "We're desperate enough"? Seriously, I know of people using Linux. I know certain niches (but noone personally) that use *BSD. But I've never heard of anyone using the HURD as anything but their pet hacking project. An OS really is a thing that rots, just keeping up with changing hardware is a big job.

    I'm sure Linux has several more layers of beureucracy and are far more critical to what code goes in there, but I think it comes with the territory. If you got code in the main kernel, it's not just for pet projects that noone will really scream if it panics. Fumble it up so linux machines go down or suffer data corruption, and there'll be many server administrators and others who'll be pissed at you.

    It's too easy to say there can't be issues, but I think it's telling that Linux is just Linux and *BSD has four (free, open, net and dragonfly) plus Darwin in OS X. While I'm sure you can say that's because the whole core team are croonies with the benevolent dictator, it tells me there's not been a sufficiently large group of people that's been sufficiently turned off that they made a competitive fork.

    I'd recommend to take another look at the code, is it documentad properly? Is it written the right coding style? Would the code affect other cases than the one you're trying to solve (eg: server vs desktop speed)? Is it a hack for something that shouldn't be solved at that level? Does it require any interfaces to change? I guess it's not easy to say without knowing what it's about, but if it just comes as a code snippet from far left field it does need to prove itself.
    --
    Live today, because you never know what tomorrow brings
  15. Re:What for? by Nutria · · Score: 2, Interesting
    The justification is, if the X server crashes, the kernel can restore the display to a usable state.

    Every time I've had X crash, it's brought me right back to the console, with no issues or problems.

    But then, I don't use [xgk]dm, nor do I use DRI. This seems like a really Microsoft-like Bad Idea to me...

    --
    "I don't know, therefore Aliens" Wafflebox1
  16. Re:What for? by siride · · Score: 4, Interesting

    Because the kernel manages hardware resources. Modesetting and graphics memory management should be done by real drivers in the kernel, just like everything else. Right now, you basically have two driver frameworks managing the video hardware (and possibly more): the kernel's own framebuffer and the X.org drivers, which already have DRM shims in kernelspace. That is way too complicated and why anybody thinks having two drivers competing for a single piece of hardware is a good idea is beyond me. There is a segment of the Unix population that seems to think that anything that's been done for longer than, say, 10 years, is automatically correct and anybody who chooses to change things is automatically wrong. FWIW, Linux and the open source BSDs are the only Unices that have had X modesetting and basic video driver functionality OUTSIDE the kernel. The commercial Unices had special X drivers in the kernel, Mac OS X obviously has kernel mode graphics support, as does Windows, although it is partitioned off from the rest of the kernel to some degree. And which OS has the most problems with graphics drivers, crashes and lockups related to that? Linux...

  17. Re:Thanks but no thanks by mehemiah · · Score: 1

    OK so never mind that the people on hurd are already thinking about this hardware changing thing but HURD is an architecture level project, which means that its solutions are mostly architecture independent. The Fragmentation among bsd descendants are, because its the similarities that are mostly cosmetic. This puts impasses on the D in bsD, Distro. Darwin doesn't have the same kernel interface as the other BSDs (note the difference in driver programming method).

  18. iKonqueror == Safari by tepples · · Score: 4, Funny

    iKonqueror A Mac-style web browser using a KHTML fork? We already have that, except the i is at the other side of "Safari".

    emac.. err imacs Apple has made both iMac and eMac computers. The eMac was introduced when some teachers found the Luxo Jr. style iMac G4 not durable enough for the K-12 market.

    even ililo? You'll get iLilo only if you buy Apple's embroidery machine, the iStitch. Thanks to a deal between Apple and Disney, brokered with the help of Disney plurality shareholder Steve Jobs, the iStitch comes preloaded with Disney patterns.
  19. DRM? by tepples · · Score: 1, Funny

    Right now, you basically have two driver frameworks managing the video hardware (and possibly more): the kernel's own framebuffer and the X.org drivers, which already have DRM shims in kernelspace. I thought DRM shims in the kernel space is part of what screwed up Windows Vista.
    1. Re:DRM? by Gordonjcp · · Score: 1

      "Direct Rendering Manager", not "Digital Rights Manglement"

  20. Spam by julesh · · Score: 1

    Wow. I've just realised that I never see spam on slashdot; this is the first one I ever remember seeing.

  21. BSOD explanation by Anonymous Coward · · Score: 2, Informative

    BSOD here does not mean "Microsoft-style reliability".

    Currently, if the kernel panic, and X is shown, the machine just locks up.

    With kernel mode-setting, the kernel will be able to switch out of X and print panic to the screen. This is very helpful to developers, and for bug reports.

    The downside is not decreased reliability, but that the normal user will panic too (and not just the kernel).

    Of course, the more code we have in the kernel, the more reasons to oops, but that hardly happens on distribution kernels, as the bugs were mostly flushed out.

  22. Re:What for? by MrHanky · · Score: 2, Insightful

    Then you don't have a recent ATI card. The free driver will hard crash my system when playing video through Xv (this is with an experimental driver pulled from the GIT tree), the proprietary driver will freeze the system on log-out (with K/GDM). An X11 error can easily take down Linux, even if you don't use DRI.

  23. Finally - Linux BSOD by daffmeister · · Score: 3, Funny

    The final impediment removed to allow "the year of linux on the desktop".

  24. Great, but... by Rysc · · Score: 1

    This is an important feature for improving user experience, if nothing else, but I worry. New things are untested. Untested things have bugs. Buggy things don't always work well. VT switching is flawless, even if it's a bit ugly. I worry about the reliability of this in crash scenarios.

    Suppose X is locked up. Today I can perform a VT switch and get a pretty responsive console, if the keyboard still responds. From there the offending program, or X, can be killed and the system recovered. Can I still do that? Probably, but I worry.

    --
    I want my Cowboyneal
    1. Re:Great, but... by msuarezalvarez · · Score: 1

      Can I still do that? Probably, but I worry.

      Why do you worry? Why don't you simply find out whether what you want can still be done and, if the answer is no, then worry?...

    2. Re:Great, but... by makomk · · Score: 1

      If anything, this should improve VT switching when X locks up. Currently, only X itself knows how to VT switch out of X, so if it really, totally locks up, you can't VT switch. With kernel modesetting, the kernel knows how to switch the mode back correctly even if X has died totally.

  25. Linked Videos by vigilology · · Score: 1

    Why is there a motherboard obscuring half the screen in those videos? Did he just put the camera down without even looking to see what it was looking at? Be a little more professional, for goodness sake.

  26. Compile Your Own Kernel by turgid · · Score: 1

    I still compile my own kernels and it's quite time consuming, but it'll be worth it to turn these features off. I'm sure all the major distros will offer kernel packages with these misfeatures disabled.

    --
    Stick Men
    1. Re:Compile Your Own Kernel by feld · · Score: 1

      there's this cool thing called modules. you should read about them.

    2. Re:Compile Your Own Kernel by turgid · · Score: 1

      there's this cool thing called modules. you should read about them.

      Yes, I've written a couple. Some parts of the kernel are enabled/disabled by a compile-time option. They are bigger than modules. Part of the infrastructure.

      --
      Stick Men
  27. No more rogue mode-setting apps by pdr77 · · Score: 1

    Ever tried out a new game and it borked up so bad you had to ssh in from somewhere else and do a reboot? Well, in my opinion, the best part about this feature is that from now on, you should be able to just bring up a VT with Ctrl-Alt-Fx and just kill the rogue process! Of course putting more into the kernel, like complex rendering operations, would be a mistake, but setting the video mode should have been in there years ago. Now all we need is a better system for getting notifications of the vertical retrace!

  28. Re:What for? by LiquidFire_HK · · Score: 1

    If you have the Alt+SysRq key combinations enabled in the kernel, you can usually sync & reboot even when X has grabbed the keyboard and frozen.

  29. Re:What for? by CoreDump01 · · Score: 1

    In that case Alt+SysRq+r switches your keyboard into "raw" mode which lets you usually change into a VT via Ctrl+Alt+1 to recover your system manually.