Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 39

Thread: NVIDIA's 302 Linux Driver Finally Has RandR 1.2/1.3

  1. #11
    Join Date
    Feb 2012
    Posts
    423

    Default

    Quote Originally Posted by asdx View Post
    Is that nothing? Maybe.
    It's not nothing. But it won't make the things you want done faster. That requires writing code. And repeating "does it have KMS, Wayland?", won't get that code written faster.

    Quote Originally Posted by asdx View Post
    I don't demand things to be done "right now", I only express my ideas and what I think is important to do.
    Your posting history shows a different picture. An example, there's more: click. Basically, your tone is... off, to say it mildly.

    Quote Originally Posted by asdx View Post
    Quite frankly, I wouldn't be able to contribute to the blob even if I wanted to, since it's all closed-source software.
    True, but you could contribute to Wayland and Mesa and such. And by contribute I mean more than just bug reports. I can do that with the nvidia driver too, I did in fact, and Nvidia confirmed the report and fixed the issue in one of the next driver versions.

  2. #12
    Join Date
    Apr 2012
    Location
    Canada
    Posts
    42

    Default

    Can anyone confirm a fix for the older card slow downs that was introduced in 295.40?

    Quote Originally Posted by Gusar View Post
    And about KMS, this has already been explained before: KMS is an implementation detail, it's one possible way of doing modesetting. Nvidia has no reason to support it, they already have their own implementation of kernel modesetting. The people demanding KMS from Nvidia don't actually want KMS, what they want is a high-res console. Which Nvidia probably could provide, if they had incentive (read: if one of their high-paying customers wanted it).
    I have to ask though: Why is a high-res console so important? I bet most of the people demanding KMS from Nvidia are using X all the time.
    A flicker free boot would be nice, though I'm still generally very impressed with nvidia's effort.

  3. #13
    Join Date
    May 2011
    Posts
    1,440

    Default

    There's no such thing as an nvidia story without somebody complaining about so-called lack of KMS support.

  4. #14
    Join Date
    Apr 2010
    Posts
    704

    Default

    Quote Originally Posted by Gusar View Post
    And about KMS, this has already been explained before: KMS is an implementation detail, it's one possible way of doing modesetting. Nvidia has no reason to support it, they already have their own implementation of kernel modesetting. The people demanding KMS from Nvidia don't actually want KMS, what they want is a high-res console.
    Actually, no. You're right, it's an implementation detail, but it's a significant one. For the open drivers, KMS provides a single consistent method of mode setting, meaning that we have a solution that works for the console, for X, for Wayland, and anything else that might come up. It means that even lacking a decent hardware-accelerated driver, there's always the option to fall back to framebuffer.

    By not supporting KMS, Nvidia can't do that. You can't write a system that, e.g switches to a high-res mode for a bootsplash screen, then seamlessly hands over to X. Nor can you switch between X and a console without a mode switch. It can't even co-exist with the KMS support that the Nouveau guys have added. And that's because all that Nvidia provide is an X driver - a very good one, to be sure, but one which provides no integration with the standard way of doing things on Linux.

  5. #15
    Join Date
    Apr 2007
    Location
    Arctic circle, Finland
    Posts
    271

    Default

    Quote Originally Posted by Mystro256 View Post
    Can anyone confirm a fix for the older card slow downs that was introduced in 295.40?
    ...
    Not sure but those should be fixed according to nvidia driver team:
    http://www.nvnews.net/vbulletin/show...4&postcount=31

  6. #16
    Join Date
    Apr 2012
    Location
    Canada
    Posts
    42

    Default

    Quote Originally Posted by tuke81 View Post
    Not sure but those should be fixed according to nvidia driver team:
    http://www.nvnews.net/vbulletin/show...4&postcount=31
    Thanks a lot!

  7. #17
    Join Date
    May 2011
    Posts
    1,440

    Default

    Quote Originally Posted by Delgarde View Post
    Actually, no. You're right, it's an implementation detail, but it's a significant one. For the open drivers, KMS provides a single consistent method of mode setting, meaning that we have a solution that works for the console, for X, for Wayland, and anything else that might come up. It means that even lacking a decent hardware-accelerated driver, there's always the option to fall back to framebuffer.

    By not supporting KMS, Nvidia can't do that. You can't write a system that, e.g switches to a high-res mode for a bootsplash screen, then seamlessly hands over to X. Nor can you switch between X and a console without a mode switch. It can't even co-exist with the KMS support that the Nouveau guys have added. And that's because all that Nvidia provide is an X driver - a very good one, to be sure, but one which provides no integration with the standard way of doing things on Linux.
    Are those deficiencies really significant to the average user base though?

    I even get flicker during boot on Windows 7 (XP is far worse) and it's not really a popular complaint.

  8. #18
    Join Date
    Feb 2012
    Posts
    423

    Default

    Quote Originally Posted by Delgarde View Post
    By not supporting KMS, Nvidia can't do that. You can't write a system that, e.g switches to a high-res mode for a bootsplash screen, then seamlessly hands over to X. Nor can you switch between X and a console without a mode switch.
    Err, why not? Nvidia could write a fbcon driver that works on top of their modesetting which would do exactly that. There's no magic in KMS, it's just the X and the fbcon drivers cooperating. If Nvidia wrote a fbcon driver, they could also write such cooperation into it.

    Quote Originally Posted by johnc View Post
    Are those deficiencies really significant to the average user base though?
    I even get flicker during boot on Windows 7 (XP is far worse) and it's not really a popular complaint.
    This. And on my machine, I already get plenty of flickering in the boot process, before the machine even gets to Linux (hmm, does EFI fix that? I'm still in the BIOS world ). So one more flicker from console to X doesn't make any difference.
    Last edited by Gusar; 05-02-2012 at 05:54 PM.

  9. #19
    Join Date
    Apr 2010
    Posts
    704

    Default

    Quote Originally Posted by Gusar View Post
    Err, why not? Nvidia could write a fbcon driver that works on top of their modesetting which would do exactly that. There's no magic in KMS, it's just the X and the fbcon drivers cooperating. If Nvidia wrote a fbcon driver, they could also write such cooperation into it.
    Why not? Because while Nvidia *could* do those things, they haven't. That's why not.

    I'm certainly not faulting them on the work they've done - for nearly a decade now, they've had the best supported graphics hardware on Linux, for those who don't mind binary drivers. It'd just be nice if they could adapt their work to fit the 'standard' way of working. Of course, I don't expect them to port their graphics driver to DRM, but the modesetting would be nice.

  10. #20
    Join Date
    Feb 2012
    Posts
    423

    Default

    Quote Originally Posted by Delgarde View Post
    Why not? Because while Nvidia *could* do those things, they haven't. That's why not.
    You were writing as if it was impossible for them to do so, as if there's a technical limitation or something. But they could do it, and they don't need KMS for it.

    Quote Originally Posted by Delgarde View Post
    I don't expect them to port their graphics driver to DRM, but the modesetting would be nice.
    But why? They don't need to, to provide the things people want when they say "we want KMS".

    xrandr is a bit different, it can do something twinview wasn't capable of - rotating just one display in a multi-display scenario. But besides that I'm not aware of any limitations twinview had, other than needing nvidia's tools to set it up, as opposed to using standard xrandr tools.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •