If everyone will please read Benh's original post describing this... Ben and I
had been emailing on this topic before he wrote this.
--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> I agree with the idea of moving the EDID decoding & mode selection to
> userland. In this regard, though, I b
I would really like to keep a single h file for the IOCTL defines. There are
equivalent drm.h's, like radeon_drm.h, files for each of the drivers too. We
could make a user space wrapper that just 'typedef uint16_t __u16' for user
space and then includes the kernel version. Or we could write a scri
On Tuesday 11 May 2004 18:20, Dave Airlie wrote:
> > Ick, you can't use "int" as an ioctl structure member, sorry. Please
> > use the proper "__u16" or "__u32" value instead.
>
> I just looked at drm.h and nearly all the ioctls use int, this file is
> included in user-space applications also at th
Would int16_t and int32_t work? Those int's were in there before I started
working on it. __u16 and __u32 are Linux kernel defines that aren't always there
in user space.
I would much rather have one h file than two. When we had two the variable and
structure names, comments, etc had drifted over
> > care to comment?
>
> Is this a case where somebody is *really* including kernel headers in userspace
> and we need to smack them, or are they using a copy that's been sanitized
> (and possibly fixed)?
hmm drm.h is used by all drm users and it hasn't really been sanitised..
we probably do need
>
> Ick, you can't use "int" as an ioctl structure member, sorry. Please
> use the proper "__u16" or "__u32" value instead.
I just looked at drm.h and nearly all the ioctls use int, this file is
included in user-space applications also at the moment, I'm worried
changing all ints to __u32 will br
> 1: Design must provide a mechanism for basic mode setting in a
> device independent manner from an application with user level
> permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY involved here. Thi
> I don't think that's a good idea: dri-devel is limited to the platforms that
> have a working DRI implementation, while linux-fbdev-devel is also frequented
> by people from platforms without DRI.
>
> And there we see a communication problem again: the DRI was started without
> talking to fbdev
On Tue, May 11, 2004 at 01:09:48PM -0500, sottek wrote:
[...]
Well said! We are all behind you.
--
Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
http://www.freebsd.org/~nsouch/kgi4BSD
---
This SF.Net email is sponsored by Sleepycat
> I'm not speaking about a text mode.
> I would think on most systems the firmware would provide some reasonable
> initial mode that the kernel can use. If there is no such firmware one
> would expect there is some preboot software that is used to bootstrap the
> kernel that could do such a setu
Alan Cox writes:
> On Llu, 2004-05-10 at 12:46, Egbert Eich wrote:
> > Yes, we will most likely need OS dependent non-chipset specific wrappers,
> > but those are cheap to do - a lot cheaper than code dealing directly
> > with chipset quirks.
>
> Well the minimal kernel side stuff required t
On Tue, 11 May 2004, sottek wrote:
> Also, we probably want to drop the communication down to just one
> list? I think dri-devel seems to have the widest group of subscribers.
I don't think that's a good idea: dri-devel is limited to the platforms that
have a working DRI implementation, while linu
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY invol
Egbert Eich wrote:
David Bronaugh writes:
> Egbert Eich wrote:
>
> >I don't only want to see mode selection in user land but also mode
> >programming.
> >I keep reiterating the reasons:
> >
> >1. Mode programming for a number of chips needs to be done thru the BIOS.
> > Unless one wants to stic
Sottek, Matthew J writes:
>
> I agree. I think we are on the same page. A minimal set of features is
> all that would be part of the defined mode setting API. It is just a
> question of if some of the multi-head concepts are generic enough to
> be part of that defined set.
That's exactly the
Jon Smirl writes:
> Can you run grub or lilo on these machines?
>
> Also, these is no rule saying a device driver can't have several tables of _init
> register values that can be used to set the mode on a primary monitor at boot. I
> would just like to see all of the code that does DDC decodi
David Bronaugh writes:
> Egbert Eich wrote:
>
> >I don't only want to see mode selection in user land but also mode
> >programming.
> >I keep reiterating the reasons:
> >
> >1. Mode programming for a number of chips needs to be done thru the BIOS.
> > Unless one wants to stick a complete
Can we wrap this up the discussion and try to get to a consensus on
design requirements? I think most of the opinions are starting to
solidify enough to start hashing out the requirements and actual
design.
Also, we probably want to drop the communication down to just one
list? I think dri-devel s
Alan Cox writes:
> On Gwe, 2004-05-07 at 21:59, Egbert Eich wrote:
> > However chipset probing/display device probing and mode setting isn't
> > required to live in kernel space. Portability and system stability
> > arguments speak against it. In fact only Apple MAC users seem to
> > advocate
>Boy, I haven't really been following this too closely, but surely this
>sort of thing can be resolved with an extension mechanism or api
>versioning?
An extension mechanism is fine for eventually extending the basic
functionality, but a driver writer should not have to wait for consensus
to add
Sottek, Matthew J wrote:
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's e
>Sottek, Matthew J writes:
>>
>> I agree. I think we are on the same page. A minimal set of features
is
>> all that would be part of the defined mode setting API. It is just a
>> question of if some of the multi-head concepts are generic enough to
>> be part of that defined set.
>
>That's exactly
> This is probably related to the missing xdm-authorization code in the
> DRI built XFree86 server. Not sure though, I think it's usually only a
> problem with kdm, which tries to use xdm-auth even if it's not available
> per default (changeable in the config file). But maybe your xdm is
> conf
There are three pools of DMA memory, low (below 16MB?), normal, high (64b). If
the kernel can't identify your hardware it returns a buffer from the low pool
because it assumes it is an ISA device. With the new code the kernel can look at
the PCI capabilities of the device and the device says its su
Cedric Cellier wrote:
DRI compiled and installed cleanly.
The bug goes away !
Many thanks !
(Note : BTW, now xdm start in B&W mode, and refuses to launch X11 - I
had to install another login manager :-/ )
This is probably related to the missing xdm-authorization code in the
DRI built XFree86 serv
[ Please remove any subject tags when following up ]
On Tue, 2004-05-11 at 04:20, Adam Jackson wrote:
>
> You only need to trust the user if the operation could have security
> implications.
[...]
> mode setting isn't sensitive because changing the display mode isn't going
> to stomp on kern
DRI compiled and installed cleanly.
The bug goes away !
Many thanks !
(Note : BTW, now xdm start in B&W mode, and refuses to launch X11 - I
had to install another login manager :-/ )
---
This SF.Net email is sponsored by Sleepycat Software
Le
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2004-05-11 08:55 ---
(In reply to comm
The new PCI probing code seems to break the mach64 driver, it looks like
the pci_alloc_consistent is returning a different buffer when the driver
uses the new probing scheme, this is messy to debug for me until I get
another machine I can connect to my laptop to debug it...
If i make the system f
> On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
> > Do apps manage their swap? No. I think the OS should be responsible for
> > placing the data (vertices, textures, commands) at the right/best place
> > for the HW 3D engine and the client should only fill virtual memory.
>
> >
> single kernel driver should muck with the hardware directly. However,
> I'd like to point out again that it doesn't follow that the DRM and the
> framebuffer device must merge to a single entity (which 'has to be' the
> DRM if you ask some people, the framebuffer device if you ask
> others...).
On Mon, 10 May 2004, Alan Cox wrote:
> On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> > Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
> > moved to userspace. The networking code alone is over 17 megs in size.
>
> Not on my box. Nothing like it. Although to answer th
> > But we are rendering to draw fonts, clearing a area of the screen,copyarea.
> > If we are to have a universal solution it needs to OpenGL. Either that or
> > mode switching stays in the kernel.
>
> Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
> that you can't make
33 matches
Mail list logo
