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 support.
On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] 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
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
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 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 pushed
On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer 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 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
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 implements
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
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 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 have two
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
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 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] Dnzer wrote:
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
I think yourself and
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
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
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
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,
Jesse
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
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
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 (or
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
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 to
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'd like to
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 button events
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 other
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
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 to own it,
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
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 myself.
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 fbcon
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 too much as he can see where the potential
ineffecienes with saving/restore card state
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 too much as he
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 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 think your
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
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
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
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
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
--- 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 would be most
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 else..
--- 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 driving
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 paths
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). FB
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 FUD
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 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.
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
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 information,
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
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 have
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
stuff,
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 stealth
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 been
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
That way it is
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 the
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
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
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 card
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 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.
If
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.
If
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.
User 1
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 switch
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 actually
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
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 play
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 Dnzer | Debian (powerpc), X and DRI developer
Libre software
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 would seem
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 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:
display buffer
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
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
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
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
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: YOU
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
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 ;-)
Getting the
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 of this,
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 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
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 to do their
--- 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 make things
That is expected behavior. Without vesa the savage driver can take
complete control of the hardware and mark everything in use.
With vesa loaded the DRM driver will detect that it is loaded and
switch into stealth mode. In stealth mode DRM uses all of the
resources without telling the kernel. It
On Gwe, 2004-09-10 at 16:11, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load it separately.
Your personal plan.
On Fri, 10 Sep 2004 16:14:38 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 16:11, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load it
On Fri, 10 Sep 2004 17:00:33 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 17:37, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
My personal plan has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various aspects of the plan were
Addressed and eliminated would be closer. The
PS: Don't get me wrong - we have to address the main points on that list
(the ones on the list not in your head). The last thing I want to see is
another person march off into the distance with a framebuffer agenda and
a lack of understanding about the importance of getting
from where we are now
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.
Philipp
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod
On Fri, 10 Sep 2004 18:04:19 +0100, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
My personal plan has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various
I tested your patch with Savage, without VesaFB:
# cat /proc/iomem
...
d000-d7ff : PCI Bus #01
d000-d7ff : :01:00.0
d000-d7ff : savage
...
dc00-ddff : PCI Bus #01
dd00-dd07 : :01:00.0
dd00-dd07 : savage
...
On my notebook, where
You are focusing on the resource claiming problem. That is an easy
problem to solve, it's also not the one that is causing the hard
problems.
I have to agree with Jon, nobody has addressed any of the issues he raises
except the one that is quite simple to solve, resource sharing is easy,
I
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 same
On Gwe, 2004-09-10 at 14:31, Felix Khling 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 all
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
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 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 freebie
1 - 100 of 111 matches
Mail list logo
