* Re: your mail
@ 2004-08-16 15:42 Jon Smirl
2004-08-16 23:55 ` Dave Airlie
0 siblings, 1 reply; 4+ messages in thread
From: Jon Smirl @ 2004-08-16 15:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel, Dave Airlie
Graphics drivers in the kernel are broken. The kernel was never
designed to have two device drivers trying to control the same piece of
hardware.
I have posted a long list of 25 points that we are working towards to
unify things. http://lkml.org/lkml/2004/8/2/111 The PCI ROM patch that
has been posted recently addresses the first one.
In the meanwhile we have to transition somehow between what we have and
where we are going. Since fbdev has taken the path to pretend that DRM
doesn't exist DRM has to go through a lot of trouble to work when fbdev
is in the system. DRM also has to work when fbdev is not in the system.
DRM is being reworked into a first class driver with full support for
2.6 and hotplug. Part of being a first class driver means that DRM has
to register itself with the kernel like a real driver and claim all of
it's resources. I'm also fixing the driver to use 2.6 module parameters
and to support dynamic assignment of minors. Sysfs support is in the
patch being discussed.
But DRM still has to live with existing fbdev drivers. The same DRM
code is used in 2.4 and 2.6 so existing fbdev drivers are not going
away anytime soon. When DRM detects a fbdev it will revert back into
stealth mode where is attaches itself to the hardware without telling
the kernel that it is doing so. DRM can not use stealth mode when
running without fbdev present since it will mess up hotplug by not
marking the resources in use.
I don't believe the ordering between fbdev and DRM is an issue. If you
are using fbdev you likely have it compiled in. In that case fbdev
always loads first and DRM second. In the non-ppc world, most of us
have x86 boxes which don't use fbdev. In those machines DRM needs to be
a first class driver. In the real world I don't know anyone other than
a developer who would load DRM first and then fbdev. If this is a
problem you will need to fixed fbdev to fall back into stealth mode
like DRM does.
I would like to encourage you to work towards the points on the above
referenced list. It has been widely distributed and commented on. It
has been posted to lkml, dri-dev, fb-dev and xorg lists and discussed
at OLS.
Sorry, but I can't add an In-Reply-To header in the middle of thread on
yahoo. cc me on a reply to the main thread so that I will pick up the header.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: your mail
2004-08-16 15:42 your mail Jon Smirl
@ 2004-08-16 23:55 ` Dave Airlie
2004-08-17 0:22 ` DRM and probing (was: your mail) Jon Smirl
2004-08-17 0:22 ` Jon Smirl
0 siblings, 2 replies; 4+ messages in thread
From: Dave Airlie @ 2004-08-16 23:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
> But DRM still has to live with existing fbdev drivers. The same DRM
> code is used in 2.4 and 2.6 so existing fbdev drivers are not going
> away anytime soon. When DRM detects a fbdev it will revert back into
> stealth mode where is attaches itself to the hardware without telling
> the kernel that it is doing so. DRM can not use stealth mode when
> running without fbdev present since it will mess up hotplug by not
> marking the resources in use.
>
> I don't believe the ordering between fbdev and DRM is an issue. If you
> are using fbdev you likely have it compiled in. In that case fbdev
> always loads first and DRM second. In the non-ppc world, most of us
> have x86 boxes which don't use fbdev. In those machines DRM needs to be
> a first class driver. In the real world I don't know anyone other than
> a developer who would load DRM first and then fbdev. If this is a
> problem you will need to fixed fbdev to fall back into stealth mode
> like DRM does.
This is a good point, we are being forced into stealth mode by the fb
driver if they want to load after us they should respsect us and do the
same, (nope this isn't an us and them, DRM vs fb - I think we have a
solution and are heading the correct direction)...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 4+ messages in thread
* DRM and probing (was: your mail)
2004-08-16 23:55 ` Dave Airlie
@ 2004-08-17 0:22 ` Jon Smirl
2004-08-17 0:22 ` Jon Smirl
1 sibling, 0 replies; 4+ messages in thread
From: Jon Smirl @ 2004-08-17 0:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Dave Airlie, torvalds, Andrew Morton, linux-kernel
Building a shared stub driver that fbdev and DRM both use is just a
waste of time. While it may simplify probing in the current model it
does nothing to fix the conflicting use of registers and framebuffer
memory management. The stub driver approach touches about 25 device
drivers and would be a huge testing problem. Probing is not what
crashes systems; the other two issues cause the crashes.
Please read the overall plan for fixing things:
http://lkml.org/lkml/2004/8/2/111
We welcome anyone who wants to help work on the solution.
That list is not set in stone but many, many people have reviewed and
commented on it. It was started in March and it has under gone many
revisions. If you think there are problems with this plan please let us
know now since several of the items have already been written and
others are being worked on. Most graphics discussion and review happens
on dri-dev and fb-dev not lkml.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 4+ messages in thread
* DRM and probing (was: your mail)
2004-08-16 23:55 ` Dave Airlie
2004-08-17 0:22 ` DRM and probing (was: your mail) Jon Smirl
@ 2004-08-17 0:22 ` Jon Smirl
1 sibling, 0 replies; 4+ messages in thread
From: Jon Smirl @ 2004-08-17 0:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Dave Airlie, torvalds, Andrew Morton, linux-kernel
Building a shared stub driver that fbdev and DRM both use is just a
waste of time. While it may simplify probing in the current model it
does nothing to fix the conflicting use of registers and framebuffer
memory management. The stub driver approach touches about 25 device
drivers and would be a huge testing problem. Probing is not what
crashes systems; the other two issues cause the crashes.
Please read the overall plan for fixing things:
http://lkml.org/lkml/2004/8/2/111
We welcome anyone who wants to help work on the solution.
That list is not set in stone but many, many people have reviewed and
commented on it. It was started in March and it has under gone many
revisions. If you think there are problems with this plan please let us
know now since several of the items have already been written and
others are being worked on. Most graphics discussion and review happens
on dri-dev and fb-dev not lkml.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-08-17 0:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-16 15:42 your mail Jon Smirl
2004-08-16 23:55 ` Dave Airlie
2004-08-17 0:22 ` DRM and probing (was: your mail) Jon Smirl
2004-08-17 0:22 ` Jon Smirl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).