Announcement

Collapse
No announcement yet.

SimpleDRM Will Likely Be Merged In Linux 3.15

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SimpleDRM Will Likely Be Merged In Linux 3.15

    Phoronix: SimpleDRM Will Likely Be Merged In Linux 3.15

    Besides going for enabling DRM render-nodes by default, David Herrmann is looking to land a bunch of other DRM patches for the Linux 3.15 kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    SimpleDRM was really the missing piece to switch to a full DRM system in case of difficult graphic hardware.

    Anyone know if SimpleDRM and xf86-video-modesetting will allow user to set custom resolution for the "framebuffer" and xorg sessions? UMS vesa was too limited in choice of resolutions and vesafb video parameter is broke for quite some years now (I never though of uvesafb as a serious substitute).

    Comment


    • #3
      Originally posted by Fresh_meat View Post
      SimpleDRM was really the missing piece to switch to a full DRM system in case of difficult graphic hardware.

      Anyone know if SimpleDRM and xf86-video-modesetting will allow user to set custom resolution for the "framebuffer" and xorg sessions? UMS vesa was too limited in choice of resolutions and vesafb video parameter is broke for quite some years now (I never though of uvesafb as a serious substitute).
      If you're referring to xorg sessions then xrandr should just work.

      However, and I'm just guessing here, you have an nVidia GPU, right? Maybe trying to sort out GRUB's resolution? Plymouth perhaps? Well, if that's the case, then you're barking on the wrong tree. Though this might change soon as Steam is showing more and more promise while Windows is losing market, currently, nVidia's driver is to blame for not implementing the APIs the kernel has in place for such operations.

      Though, I suppose Herrmann's re-fracturing and cleanups might encourage nVidia to use these new APIs...

      Comment


      • #4
        Originally posted by c117152 View Post
        If you're referring to xorg sessions then xrandr should just work.

        However, and I'm just guessing here, you have an nVidia GPU, right? Maybe trying to sort out GRUB's resolution? Plymouth perhaps? Well, if that's the case, then you're barking on the wrong tree. Though this might change soon as Steam is showing more and more promise while Windows is losing market, currently, nVidia's driver is to blame for not implementing the APIs the kernel has in place for such operations.

        Though, I suppose Herrmann's re-fracturing and cleanups might encourage nVidia to use these new APIs...
        Actually I was talking about some hard to solve use cases.

        Let me explain :

        Just a few years ago I was running a small business and all my trainees used diskless Linux desktop. The computer was old even by those days : pentium 4 and so on (I ENJOYED my electrical bills at those times ...), but that was fairly enough for them, CPU speaking, but for the graphic part, that was another story. Actually, some of the graphic cards wasn't properly recognized, and I used every kind of them : ati radeon, ati rage, nvida geforce, ... (I was kind enough to spare them the old savage and cirrus logic adapters ). Anyway, I had to use the vesa driver for some of them but it was a problem with wide resolution (1280x800 for instance), and the result was quite poor.

        In the same way, I got stuck with a poor vga= (or sometimes nothing at all) parameter in grub for debuging kernel panics (the lack of serial ports really suxx ), in situation were newer kernel weren't an option (I was using openVZ kernels). And yes I compiling the kernel with the only the required frambuffer device support or KMS when avaliable but I still ran into issues.

        And for my personal use, I usually hit some very anoying problem like : that new graphic card has a new GPU which is a slightly revision of the chip and it broke the graphic stake, so I will need to use the splandid vesa driver wich sucks the whole hell on my wide display (and there is no more 4:3 display those days anyway) so I can still use my multi boot setup while waiting for a propper suppot on Linux.

        So yeah, a more flexible generic KMS driver and DRM would really help in case nothing else work, at last it would be better that vesafb, efifb, vesa, ...

        And no, I don't use nvidia cards since a while now, I don't want to give money to company who agree to such terrible business model, even if that means I am lacking of features (I must say the mess the blower of my HD6870 made without DPM was VERY ANOYING).

        Comment


        • #5
          Oh, I see what you're saying. Then, still No. There will never be a generic-fit-all graphics driver. At most the target APIs would get cleaned up and will be easier to work with which might shorten the release cycles a bit. And hopefully help sorting out the bootloader (vga=) side of things as well as for the property drivers.
          However, there will never come a time when a new graphics card will come out to market and you'll be able to just plug it in and get anything but text-mode \ broken vesa support unless the manufacturer releases the driver in advance and the distribution will pick it up early on as well. Modern cards don't even have their power-management (voltage throttling \ fans...) baked in. It's all software driven. i.e. drivers...

          Mind you it's the same for Windows. When Vista first came out it was so poorly supported by some OEMs that you'd end up with 800x600 for the first few month after release. I think Windows 8 had\has similar issues but I only see people using it when it comes bundled-in. That is, people building their own machines and buying their own GPUs just use Windows 7 \ Linux.

          Originally posted by Fresh_meat View Post
          Actually I was talking about some hard to solve use cases.

          Let me explain :

          Just a few years ago I was running a small business and all my trainees used diskless Linux desktop. The computer was old even by those days : pentium 4 and so on (I ENJOYED my electrical bills at those times ...), but that was fairly enough for them, CPU speaking, but for the graphic part, that was another story. Actually, some of the graphic cards wasn't properly recognized, and I used every kind of them : ati radeon, ati rage, nvida geforce, ... (I was kind enough to spare them the old savage and cirrus logic adapters ). Anyway, I had to use the vesa driver for some of them but it was a problem with wide resolution (1280x800 for instance), and the result was quite poor.

          In the same way, I got stuck with a poor vga= (or sometimes nothing at all) parameter in grub for debuging kernel panics (the lack of serial ports really suxx ), in situation were newer kernel weren't an option (I was using openVZ kernels). And yes I compiling the kernel with the only the required frambuffer device support or KMS when avaliable but I still ran into issues.

          And for my personal use, I usually hit some very anoying problem like : that new graphic card has a new GPU which is a slightly revision of the chip and it broke the graphic stake, so I will need to use the splandid vesa driver wich sucks the whole hell on my wide display (and there is no more 4:3 display those days anyway) so I can still use my multi boot setup while waiting for a propper suppot on Linux.

          So yeah, a more flexible generic KMS driver and DRM would really help in case nothing else work, at last it would be better that vesafb, efifb, vesa, ...

          And no, I don't use nvidia cards since a while now, I don't want to give money to company who agree to such terrible business model, even if that means I am lacking of features (I must say the mess the blower of my HD6870 made without DPM was VERY ANOYING).

          Comment


          • #6
            @Fresh_meat: Vesa is a generic driver. As such, it can only use resolutions that are in the VBIOS of the GPU. Getting other resolutions requires knowledge of how the GPU's output logic works. This logic is specific to the GPU (for example, look at the Radeon Display Hardware list, more or less every generation of GPUs has a new output engine), and if you add such GPU-specific knowledge to a driver, it's no longer a generic driver. So what you want simply isn't possible, it would defeat the point of having a generic driver.

            Comment


            • #7
              Originally posted by Gusar View Post
              @Fresh_meat: Vesa is a generic driver. As such, it can only use resolutions that are in the VBIOS of the GPU. Getting other resolutions requires knowledge of how the GPU's output logic works. This logic is specific to the GPU (for example, look at the Radeon Display Hardware list, more or less every generation of GPUs has a new output engine), and if you add such GPU-specific knowledge to a driver, it's no longer a generic driver. So what you want simply isn't possible, it would defeat the point of having a generic driver.
              Well, I far as I remember, my former associate used uvesafb on his 1920p XPS with a dual Geforce setup, and he got a native resolution (of cause no recklocing) despite uvesafb being generic.

              Comment


              • #8
                Originally posted by Fresh_meat View Post
                Well, I far as I remember, my former associate used uvesafb on his 1920p XPS with a dual Geforce setup, and he got a native resolution (of cause no recklocing) despite uvesafb being generic.
                If the 1920p resolution was the VBIOS, sure. There's no fixed list of resolutions that are in there, it's different on every GPU. Well, there's the standard vesa resolutions, but GPUs can and do sometimes have additional resolutions specified too, including widescreen ones.

                Comment


                • #9
                  Originally posted by Gusar View Post
                  If the 1920p resolution was the VBIOS, sure. There's no fixed list of resolutions that are in there, it's different on every GPU. Well, there's the standard vesa resolutions, but GPUs can and do sometimes have additional resolutions specified too, including widescreen ones.
                  And that where a "SimpleDRM" driver, which actually follows RandR specification can help.

                  With plain VESA, you usually have to guess a "magic number" for a video mode (or at least pick it from a 10-page long list. As mentionned, GPU can sometime have additional resolutions, and on some graphic cards, this list can get quite long).
                  then you give that mode number to the vesa driver at boot time, which will switch into this mode, attach a framebuffer to it, and don't touch it any more.

                  At least as SimpleDRM follows the RandR specifications, it would be possible to use the standard XRandR to set video modes as one likes, and the drivers will abstract all the VESA specifics.

                  This could be even driven further with some VESA extensions:
                  - AFAIK (I haven't been directly playing with VESA since my DOS days, a long time ago) there are already VESA extensions to access DDC (and thus get info about the monitor attached).
                  - perhaps some extensions to help basic functions like mode settings to an arbitrary resolution (AFAIK this doesn't exist yet. Or at least didn't exist in the latest SPEC I've read, but perhaps it has moved on a bit since last time).

                  Comment

                  Working...
                  X