On Llu, 2004-09-13 at 18:50, Jon Smirl wrote:
> How's this going to work with hotplug? Hotplug works by associating a
> device with a driver by the PCI ID table contained in the driver. Both
> the fbdev and DRI drivers currently contain the same PCI IDs for the
> cards that the chipsets they suppor
On Tuesday 14 September 2004 00:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
>
> fbdev only sets the mode on a single head. My cards have more that one
> head. When I tried adding mode setting to DRM so that I could handle
> my
On Mon, 13 Sep 2004 13:42:19 -0700, David Bronaugh
<[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> >How would any of these plans handle power management and ACPI events?
> >I'd like to be able to suspect my laptop with the DRI enabled, or have
> >the DDX (or whatever) handle acpi lid and butt
On Mon, 13 Sep 2004 16:41:06 -0400
Alex Deucher <[EMAIL PROTECTED]> wrote:
> On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> > On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > > How would any of these plans handle power management and ACPI events?
> > > I
On Monday 13 September 2004 04:41 pm, Alex Deucher wrote:
> On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> > On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > > How would any of these plans handle power management and ACPI events?
> > > I'd like to be able
Alex Deucher wrote:
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
Since I've been doing a little b
On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> > How would any of these plans handle power management and ACPI events?
> > I'd like to be able to suspect my laptop with the DRI enabled, or have
> > the DDX (o
On Monday 13 September 2004 03:21 pm, Alex Deucher wrote:
> How would any of these plans handle power management and ACPI events?
> I'd like to be able to suspect my laptop with the DRI enabled, or have
> the DDX (or whatever) handle acpi lid and button events or put the
> chip into various power m
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus Torva
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
> The IA64 people want a file/ioctl interface on the /dev/vga0 devices
> so that they can issue control calls to the active device in each "VGA
> space"
I think ppc and sparc want this too, we'll use it for issuing legacy in/out.
Thanks,
Je
It wasn't intended to stay in the PCI layer. Something needs to be
done about hotplugging bridges. There aren't callouts from the PCI
layer for that. A hotplugged bridge can be capable of VGA routing and
have VGA devices behind it. I just started off in the PCI layer while
I figured out what hooks
How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.
So when a card gets hotplugged, which driver do I
On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
Already covered - although at the moment the question is open about who
tells the vga generic code "It has 4 heads" ?
Had a look over your class code - its
On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
> On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dïnzer wrote:
> >
> > > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> > >>
> > >> I th
Doesn't the base platform need to be designed to also treat individual
heads as resources?
fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other heads there was a big uproar that fbdev owns mode setting
On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
>
> So, as Jon rightly points out the "multiple drivers" scheme only makes
> sense in the current usage patter - you either use X or framebuffer, never
> both at the same time and you consider a few seconds per switch normal.
You are
On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
> > It depends how the various components fit together. Clearly for Radeon
> > you want everyone using the DMA command path when DRI is loaded. That
> > doesn't require "one driver"
>
> Alan, do I understand right that you are proposing to hav
On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
> It also needs something to sort out both drivers using pci_drvdata()
> to get to their private data. For example in the hotplug routines you
> only get passed a pdev and you want to use that to locate your private
> data.
The hotplug routines for vga
On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
>
> The overlay window is currently using part of what is being proposed by
> "multiple drivers" proponents. It has to make engine queiscent so it can
> write data directly to the video memory. It does *not* have to save the
> state.
It doesn't e
On Mon, 13 Sep 2004, Alan Cox wrote:
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers o
On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> Well this is what I came up with so far. It creates a vga class so you
> can bind the drivers to functions of the card (and we can add/remove
> functions later as appropriate), tells functions about each other and
> now imple
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
> However, if we want the switch from X to framebuffer to be as fast as
> switching between different text consoles (assuming they have the same
> resolution) and if we want to be able to run different Xservers on
> different consoles or Xse
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dänzer wrote:
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
> The worst things that will happen for all concerened is this:
> Jon does all this work on a merged solution outside the kernel, and it
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets push
Jon Smirl wrote:
On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. ->quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1
On Mon, 2004-09-13 at 00:42, Dave Airlie wrote:
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets pushed via the X tree and distributions
> start relasing kernels with it merged into it and it never goes into the
> main tree... it won't ma
On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dïnzer wrote:
>
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >
Alan Cox wrote:
What about if you want to use fb when in text mode (Because you get
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
back & forth between X & fb... (i.e. how I currently use it but with
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
>
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >> know they won't please Jon to
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dänzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state o
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbco
> >
> > We already have a mechanism for this: suspend/resume.
>
> Jon, you're not making sense any more.
> This discussion is just ridiculous, and I don't think it's worth cc'ing me
> if people can't try to work together, since I'm sadly not going to have
> time to actually implement any of this m
On Sun, 12 Sep 2004, Dave Airlie wrote:
>
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a
>
> > Alan, I agree with how you want to proceed with this, and keep things
> > stable, but anything short of a single card-specific driver looking after
> > the registers and DMA queueing and locking is going to have deficiencies
> > and the DRM has a better basis than the fb drivers,
>
> "I want
On Sul, 2004-09-12 at 12:36, Hamie wrote:
> But this relies on drivers co-operating with each other.
Only minimally, and providing the co-operation is easy the rest comes
out fine. We don't often get ide-disk and ide-cd people arguing over
whose fault something is
> Yeah. Would fglrx be more st
On Sat, 2004-09-11 at 14:37, Jon Smirl wrote:
> On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > > Alan, if you will commit Redhat to implementing all of the features
> > > referenced in this message
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
> > Lastly, I am not saying you have to put all the code in the same
> file.
> > All I am saying we can mandate that all Radeon HW specific code is
> linked
> > in one module - and this would mak
On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
> <[EMAIL PROTECTED]> wrote:
> > So I'd much rather see the "hey, somebody else might have stolen my
> > hardware, and now I need to re-initialize" as the _basic_ model. That just
> > allows others t
On Sad, 2004-09-11 at 22:37, Jon Smirl wrote:
> But since I've written most of the code so far I get to pick the
> details of the implementation.
Umm thats what happened to ruby and thats what happened to KGI.
> If Alan would instead like to pick the
> details I've offered to withdraw if he'll w
On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> So I'd much rather see the "hey, somebody else might have stolen my
> hardware, and now I need to re-initialize" as the _basic_ model. That just
> allows others to do their own thing, and play well together. More
> What about if you want to use fb when in text mode (Because you get
> 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
> you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
> back & forth between X & fb... (i.e. how I currently use it but with
> unacce
On Sat, 11 Sep 2004 13:29:33 -0700, Eric Anholt <[EMAIL PROTECTED]> wrote:
> To summarize, there is no "2d mode" and "3d mode." Please stop
> referring to it. If you were actually trying to talk about
> synchronization for MMIO vs DMA command submission (which is and would
You are right on all o
On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > Alan, if you will commit Redhat to implementing all of the features
> > referenced in this message:
>
> You definitly start sounding like Hans ;-)
Gett
Alan Cox wrote:
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. ->quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.
User 2's editor is never going to f
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> Alan, if you will commit Redhat to implementing all of the features
> referenced in this message:
You definitly start sounding like Hans ;-)
---
This SF.Net email is sponsored by: YO
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
http://lkml.org/lkml/2004/8/2/111
then I'll back off and go work on the X server.
Use whatever mechanism you want, but implement all of the features.
There are two main goals:
#1) Get mesa-solo runni
On Sat, 2004-09-11 at 10:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
>
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
>
> My solution is to leave the c
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
Jon, you want to get to that "Final step is to integrate the chip specific
code from DRM and fbdev". Alan doesn't even want to get there. I think
Alan just wants some simple in
On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <[EMAIL PROTECTED]> wrote:
> > Jon, you want to get to that "Final step is to integrate the chip specific
> > code from DRM and fbdev". Alan doesn't even want to get there. I think
> > Alan just wa
On Sat, 11 Sep 2004 14:05:54 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> > All register writes would occur in the driver. There is nothing
> > stopping the code that computes those register values from running in
> > user space.
> >
> > A example mode setting IO would take:
> > di
On Sat, 11 Sep 2004, Jon Smirl wrote:
My view was that PLL setting (and setting of a fixed mode) would be done
in DRM driver. This way it would be able to restore previous settings
after a lockup or respond to FB request to change modes.
However the decision of which mode to set, as well as where
On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> On Sat, 11 Sep 2004, Alan Cox wrote:
>
> > On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> >> This is a good point - if we don't need DMA or 3d acceleration we can
> >> reduce memory footprint. This
On Sat, 2004-09-11 at 13:13 -0400, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Have you looked at the radeon X driver acceleration code in the last
couple of years?
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software e
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> Jon, you want to get to that "Final step is to integrate the chip specific
> code from DRM and fbdev". Alan doesn't even want to get there. I think
> Alan just wants some simple infrastructure to let everybody pla
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem that current DRM driver would
need to be dependent on whatever driver contains the mode setting
On Sat, 11 Sep 2004, Alan Cox wrote:
> On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> > My personal preference for this whole mess has always been the "silly
> > driver" that isn't even hardware-specific, and really does _nothing_ on
> > its own. This one would be the only thing that act
On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Now it is _you_ who confuse "3D mode" and "2D mode".
THERE IS NO SUCH THING.
There is only hardware.
> How can you build a system that process swaps between these two modes?
You don't swi
On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> > User 1's game queues up 20ms of 3D drawing commands.
> > Process swap to user 2. ->quiesce() is going to take 20ms.
> > User 2's timeslice expires and we go back to user 1.
>
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2. ->quiesce() is going to take 20ms.
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
>
> User 2's editor is never going to function
On Sad, 2004-09-11 at 18:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Card dependant.
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
> My solution is to
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2. ->quiesce() is going to take 20ms.
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
>
> User 2's editor is never going to function
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> This is a good point - if we don't need DMA or 3d acceleration we can
> reduce memory footprint. This would seem that current DRM driver would
> need to be dependent on whatever driver contains the mode setting code.
>
> What do you think
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> My personal preference for this whole mess has always been the "silly
> driver" that isn't even hardware-specific, and really does _nothing_ on
> its own. This one would be the only thing that actually reserves the IO
> regions and "owns" the
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to leave the coprocessor always running and convert
everything to use the DM
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
Lastly, I am not saying you have to put all the code in the same file.
All I am saying we can mandate that all Radeon HW specific code is linked
in one module - and this would make things easier for de
On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline. DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses
On Sat, 11 Sep 2004 15:33:43 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> For example I can see the radeon DRM driver providing
>
> ->queue_commands()
> ->quiesce()
>
> to the 2D driver. And the 2D driver providing
>
> ->define_fb_layout() for DRI to provide to X
>
> Th
On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote:
> Not to step on toes, but... From what I can tell the idea is to add code
> into FB that calles functions in the DRM and vice vers. This would seam
> to add another ABI. Unless the code gets linked into one module, this
> idea has b
On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote:
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline. DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stea
On Sat, 11 Sep 2004 17:20:38 +0800, Antonino A. Daplas
<[EMAIL PROTECTED]> wrote:
> On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> > The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> > there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> >
On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
> Lastly, I am not saying you have to put all the code in the same file.
> All I am saying we can mandate that all Radeon HW specific code is linked
> in one module - and this would make things easier for developers.
And if I want dri but
On Sat, 11 Sep 2004 13:27:27 +0100, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing lowlevel
> > VGA device drivers until someone addresses why it is acceptable to ha
Thus at the very least you would want to mandate the availability of mode
setting part of FB when DRM is loaded - and they you can just as well link
the relevant code together.
You are making a generic assumption for a single card specific problem
in a specific situation. That leads to bad decisio
On Sad, 2004-09-11 at 10:20, Antonino A. Daplas wrote:
> In theory, one can have a process (kernel or userland) change the video
> mode, then provide the in-kernel driver with the necessary information
> about the layout of the framebuffer. When this in-kernel driver gets the
> necessary informati
anything else.. (remembering graphics cards are not-multifunction cards -
like Christoph used as an example before - 2d/3d are not separate
functions...)...
We've addressed this before. Zillions of drivers provide multiple
functions to multiple higher level subsystems. They don't all have to
be co
On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote:
> The thing is I know of no way to provide arbitration in such a way as to
> permit other code to access PLL registers directly.
This arises solely because the DRM and framebuffer drivers cannot find
each other and have no shared structures.
On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things
It matters immensely what the divison is because people talking doesn't
scale ..
> I'm interested in seeing what Alan comes up with, even in a non-working
>
On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
> So the IDE-CD driver and IDE-disk drivers both program registers on the
> IDE controller directly.. oh no the ide driver seems to do that.. this is
> FUD,
Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter F
On Sad, 2004-09-11 at 01:47, Vladimir Dergachev wrote:
> One driver per device. I.e. one driver per *physical* device.
This is a religion the kernel doesn't follow. Its a pointless
religion
> Lastly, one point that you appear to have missed: DRM does DMA transfers
> (among everything else).
On Sad, 2004-09-11 at 00:24, Dave Airlie wrote:
> stop saying this, it isn't true and hasn't been for years, for the mach64
> type cards I'd agree, for something even like the i810 this isn't
Its true. Its still true whether you demand people stop saying it or
not.
> true, most cards have two pat
--- Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing
> lowlevel
> > VGA device drivers until someone addresses why it is acceptable to
> have
> > two separate driver
> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the same hardware for video and not for
> anything els
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Vladimir Dergachev wrote:
> >
> > Alan,
> > I would like to disagree with you.
> >
> > On Fri, 10 Sep 2004, Alan Cox wrote:
> >
> >> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> >>
> >>> If the kernel developers can address this point I wo
On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> detection, some p
Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver drivin
Vladimir Dergachev wrote:
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA devi
Dave Airlie wrote:
2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not more so.
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most c
I still haven't seen a complete logical chain leading to that
conclusion.
The lowlevel driver could provide all the necessary arbitration and
safety measures to prevent the two from stepping on each other's toes.
The thing is I know of no way to provide arbitration in such a way as to
permit other
On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:
> >
> > You're probably right, but it still doesn't follow that this driver must
> > include all the fbdev and DRM code as well. Both fbdev and the DRM could
> > use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
>
> I thi
>
> You're probably right, but it still doesn't follow that this driver must
> include all the fbdev and DRM code as well. Both fbdev and the DRM could
> use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
>
I think your wrong, look at drivers/video/aty/radeon* and tell me wha
On Sat, 2004-09-11 at 01:50 +0100, Dave Airlie wrote:
>
> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> [...]
You're pro
The current DRM code doesn't suffer from resource conflicts anymore.
DRM now supports two modes: primary and stealth. In primary mode DRM
behaves like a Linux device driver should, it attaches to it's PCI
IDs, claims it's resources, registers with sysfs, generates hotplug
events, etc.
On the other
>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone a
On Gwe, 2004-09-10 at 19:19, Philipp Klaus Krause wrote:
> What became of the proposal of making fb a DRM client
> that I saw on dri-devel some time ago?
> It sounded like a good idea to me.
That falls out from just about all sane and non-sane ways of
tackling the problem. Its essentially a freeb
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most cards have two
On Sad, 2004-09-11 at 00:10, Jon Smirl wrote:
> I'm counting on Ian to provide the memory management code. I haven't
> even looked at it very much. The point is simply that we have to have
> something, you just can't support multiple heads without minimal
> memory management and fbdev doesn't curre
On Fri, 10 Sep 2004 23:19:42 +0100 (IST), Dave Airlie <[EMAIL PROTECTED]> wrote:
> Also I don't think what Jon has in mind is going to be truly possible and
> IMHO an efficient flexible graphics card memory management system is
> something worthy of multiple PhDs (maybe I'll go back to college), Ia
On Gwe, 2004-09-10 at 14:31, Felix KÃhling wrote:
> The first region (frame buffer and apperture) is claimed (partially) by
> vesafb, the second one (MMIO registers) is not claimed at all. I don't
> see an obvious way to fix this.
Its already fixed in the stuff I'm working on. Given the list of al
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the sa
1 - 100 of 118 matches
Mail list logo
