lkml.org 
[lkml]   [2006]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: OpenGL-based framebuffer concepts
    Good Day,

    I think this debate boils down ti a few issues that could be easily resolved.
    As far as I can tell, the OpenGL Framebuffer is for an accelerated
    console in 2D
    While expecting Intel, ATI and Nvidia to cough up specs for their
    cards, a simpler
    implementation of OpenGL for the console could be offered up.
    The existing system works well for most people and a newer system could either
    tranisition from the base or take over if the installer or distro
    supports it.
    I don't see the hardware folks releasing all the details, but I can
    see them releasing a
    mini-GL driver ala the quake era in LGPL or other comparable liscense.
    It just seems that those of us with Expensive GPUs should be able to
    get a better
    console experience.
    I think a main goal would be to allow the existing code to
    gracefully release the hardware
    for a different driver to take over, be it a Xorg driver, a GLX
    driver, an Open Source driver or
    a binary driver that 'taints' the kernel. I want X to release to
    the console in some cases
    and I want the consoles basic driver to release to the Xorg driver.
    Most 'power users' run the binary drivers just fine.

    I hope it makes sense to you guys. I love Linux and want it to get better.
    Just as the static /dev gave way to udev, the basic console should
    make/prepare the way
    for an accelerated console that uses newer and more powerful
    grapics cards to better
    use.

    Thank You for reading.
    Regards,
    Ian

    On 5/30/06, Jon Smirl <jonsmirl@gmail.com> wrote:
    > On 5/30/06, Pavel Machek <pavel@ucw.cz> wrote:
    > > Hi!
    > >
    > > > >No, to the contrary. suspend/resume can't ever work properly with
    > > > >vgacon and vesafb. It works okay with radeonfb tooday, and in fact
    > > > >radeonfb is neccessary today for saving power over S3.
    > > >
    > > > But the things is today for many users suspend/resume to RAM works for
    > > > people running X drivers, I know on my laptop that my radeon
    > > > suspends/resumes fine when running vgacon/DRM/accelerated X, it
    > > > doesn't suspend/resume at all well when running vgacon on its own of
    > > > course. or with radeonfb for that matter. so I still believe the
    > > > suspend/resume code for a card can live in userspace if necessary but
    > > > it just shouldn't be part of X... it needs to be part of another
    > > > graphics controller process.
    > >
    > > So we are mostly in agreement. I'd prefer to have suspend/resume code
    > > in kernel in cases it is simple... but separate userspace process is
    > > better than having it in X.
    >
    > Don't draw any conclusions from saying that suspend/resume works in X
    > and doesn't work on xx_fb. What matters is that a set of code that can
    > perform suspend/resumes exists at all. Once a coherent driver model is
    > designed the relevant code can be moved to the correct place.
    >
    > Another reason for moving things like this out of X is to allow the
    > implementation of alternative graphics systems. It makes no sense that
    > every new graphics system has to develop their own video and keyboard
    > drivers. ALSA is a good model for this, it is shared by everyone.
    > Imagine what things would be like if X built in drivers for every
    > sound card,.
    >
    > --
    > Jon Smirl
    > jonsmirl@gmail.com
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-30 23:18    [W:4.127 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site