[ Announcement: European Linux Event
- not limited to European contributors ]
As announced before X.Org will be present on
LinuxTag in Wiesbaden, Germany
May 3 - 6, 2006
We are still looking for volunteers who whould
like to demo some exciting new X-related
The patch below allows 32bit builds of Mesa
on 64bit (especially x86_64) systems.
The '-m32' option for gcc/g++ should work with all
versions of gcc = 3.0 - also on ia32.
Egbert.
Index: configs/linux-dri-x86
===
RCS file:
The following patches make the type of handles in libdrm
more consistent.
They allow us to later change the type of drm_handle_t
from unsigned long to unsigned int to allow 32bit and 64bit
clients and Xservers to share data structures.
Included are two patches: one for libdrm as part of DRM
and
The Mesa patch below helps to make the data passed between
the Xserver and an DRI client in the GetDeviceInfo request of
the DRI extension independ of the machine size - a prerequisite
to support mixing of 32 and 64bit DRI clients.
The patch eliminates the need to use of drmAddress in these
Dave Airlie writes:
I've made a patch against the DRM code in CVS adding a few pieces that
were missing.
The code works for me on both radeon and r128. I've also tried to test
mga however the mga code in CVS doesn't seem to work at all right now.
My guess would be idr's changes
I needed the patch below to build Mesa CVS head on
x86-64.
Otherwise gcc complained about RESTORE_FPU being undefined when
compiling t_vb_arbprogram.c
Egbert.
diff -u -r1.4 t_vb_arbprogram.h
--- src/mesa/tnl/t_vb_arbprogram.h 10 Jul 2005 11:23:10 - 1.4
+++
Alan Hourihane writes:
It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to
build because the .compat_ioctl doesn't exist in 2.6.9.
Or, at the very least, we'll need to check if compat_ioctl exists before
allowing compilation.
Well, that may be the way to go. The code
Paul Mackerras writes:
Keith Whitwell writes:
In general I'd prefer that the values passed to clients (and back again)
to be abstract tokens rather than actual addresses or offsets into some
unspecified address space.
Which should mean that 32 bits is more than ample to
Ian Romanick writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Egbert Eich wrote:
@@ -612,8 +612,7 @@
_tnl_allow_pixel_fog( ctx, GL_FALSE );
_tnl_allow_vertex_fog( ctx, GL_TRUE );
- mmesa-primary_offset = mmesa-mgaScreen-primary.handle;
-
+ mmesa
Paul Mackerras writes:
Haven't I mentined that it does? Handles that fit into 32bit
should be handed to userspace unchanged, therefore if there is any
code left that does arithmetic with these handles should continue
to work. Handles that are used as real bases should be 32bit as
Eric Anholt writes:
I've taken a look, and started writing down my understanding of handles
and offsets here:
http://dri.freedesktop.org/wiki/DrmMapHandling
Thanks for putting together this page!
As far as I could tell, math was not being done on handles. This makes
sense, since
Paul Mackerras writes:
Egbert Eich writes:
... and reinvented the weel repeating the same errors that I have
already been thru.
What errors do you refer to?
Well, I've added a few points to Eric's wiki page.
http://dri.freedesktop.org/wiki/DrmMapHandling
I would
Alan Hourihane writes:
There's another issue here.
And that's drmAddress in the 2D DDX drivers.
On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because
drmAddress is passed in the *DRIRec things break.
The client-side 3D driver gets the *DRIRec and as it's a
Paul Mackerras writes:
Egbert Eich writes:
Exactly. If we want 32 and 64-bit pices to work together we need 32bit
handles. If you pass a 64bit handle to a 32-bit client it's useless
as mmap() cannot deal with a value in offset that doesn't fit into
32 bit. - at least unless we set
Alan Hourihane writes:
On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote:
Alan Hourihane writes:
On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote:
For i810 and i830 it can just be removed as it isn't even used. The
other
drivers just need
Dave Airlie writes:
Looks like that Dave Airlie has pushed another set of patches
made by Paul Mackerras into the DRM code.
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Paul Mackerras writes:
Egbert Eich writes:
My patches support a wider range of chipsets (Matrox, R128 and Radeon)
and provide a framework which makes it easy to add ioctl32 support
to more chipsets.
Unfortunately your macros have the effect of increasing the effort
required
Dave Airlie writes:
I had been hoping for some more comments from the senior DRI hackers.
Egbert's patch takes somewhat the opposite approach from mine; where I
extended the RADEONDRIRec structure to have space for 64-bit handles,
Egbert's patch unconditionally makes the
Paul Mackerras writes:
Egbert Eich writes:
Non of the patches that I've posted had problems with backward
compatibility.
At least not across the kernel/user space interface.
Originally I had one that wasn't however that had been fixed before
I put patches into the fd.o
Paul Mackerras writes:
Dave Airlie writes:
The changes to types need to clarify what exactly breaks where, I'm not as
worried about the interactions between X and Mesa as I am about old
Xs and new kernels...
And in context, this comes down to the expectations of existing 64-bit
Alan Hourihane writes:
On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote:
Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
support? 64bit applications are working fine, but 32bit apps always
use software rendering on my machine (Radeon 7500).
It
Dave Airlie writes:
I've started pushing the kernel bits to the kernel from Paulus, Linus has
accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
r128 and whatever other bits are in Egberts patch...
I have solved the map-handle issue differently in my code.
Also
Dave Airlie writes:
I've started pushing the kernel bits to the kernel from Paulus, Linus has
accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and
r128 and whatever other bits are in Egberts patch...
If this stuff is in the kernel, hasn't it been
Dave Airlie writes:
I was just a little perplexed (as I'm sure Egbert was too) that the bug
#943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS for at least a little while to get
tested here.
Paul and Egbert
Alan Hourihane writes:
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote:
I was just a little perplexed (as I'm sure Egbert was too) that the bug
#943
hadn't been updated by Paul and all of a sudden it appears in the kernel
first without being in the DRM CVS
Jim Gettys writes:
Which is why avoiding server grabs is imporant, as much
as possible. It takes a global lock out on the X server and
needs to be used with great care.
But you cannot rule out that some legacy client apps don't use server
grabs for strange purposes.
It may in fact be
Linus Torvalds writes:
On Wed, 12 May 2004, Dave Airlie wrote:
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 break some of these, anyone on DRI list
Sottek, Matthew J writes:
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
sottek writes:
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
David Bronaugh writes:
Egbert Eich wrote:
I don't think you want to call user mode code from inside the kernel.
The kernel could take a passive role and use the mode that a userland
program tells it is set. If all the kernel needs is a linear freambuffer
of size x * y and depth d
Alan Cox writes:
In which case bank switch is needed. Its actually not clear you need
2D accel. Its *nice* but not essential. Its becoming more and more the
case that console mode is the debug/boot interface for a device.
OK.
(I'n not talking about
VGA banking, but it seems like
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
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 x86 emulator
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 decoding
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:
--- Egbert Eich [EMAIL PROTECTED] wrote:
I fear that we will get a very Linux-centric view on device drivers.
This will leave us with device drivers for Linux and a different ones
Tell me the right non-Linux lists and I will post there too. There have been
Jon Smirl writes:
At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
sides so some of the proposed solutions
Alan Cox writes:
On Iau, 2004-05-06 at 09:39, Egbert Eich wrote:
Furthermore I'd argue that as little as necessary should live in the
kernel space. One thing that - in my opinion - should *not* live in
there is mode detection and initialization.
There is a need to handle some mode
Keith Packard writes:
Around 16 o'clock on May 6, Sottek, Matthew J wrote:
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
Sottek, Matthew J writes:
I for one have been waiting to see much of the graphics driver moved to
the kernel as well. From a vendor perspective there is quite a lot to be
gained.
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever
Jon Smirl writes:
I'm putting together a document for Kernel Summit that describes the issues
around graphics device drivers. The kernel developers are currently making first
pass comments on it. As soon as I fold their comments in I'll post it to
fb-dev, dri-dev and wherever else is
Alex Deucher writes:
We also have to consider the trade off between the interfaces a modern
graphics driver needs verses maintianing multi-platform availability.
If linux merges the FB/DRM drivers and moves certain things to the
kernel, there is nothing stopping other OS kernel
David Dawes writes:
On Fri, Nov 07, 2003 at 02:39:49PM -0800, Jon Smirl wrote:
I should be more specific, it's mapping the ROM into PCI space that the kernel
doesn't know about. Of course the kernel knows about the mapping from PCI space
to user space. During a hotplug event the kernel
Linus Torvalds writes:
could lead to problems with hotplug. XFree is also mapping PCI ROMs in without
informing the kernel and that can definitely cause problems.
Absolutely. Changing PCI configurations without telling the kernel _will_
cause problems. Especially for hotplug
Linus Torvalds writes:
On Wed, 15 Oct 2003, Michel Dänzer wrote:
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
This new scheme allows the entire PCI probing stage of xfree to be eliminated.
I'll believe it when the relevant XFree86 developers agree with you. :)
If they
Mike A. Harris writes:
The problem with the IPv6 support commited to XFree86 CVS, was
that it requires the system to have IPv6 support wether you
actually use IPv6 at all or not. In other words, if your kernel
does not support IPv6, then you can not use XFree86 CVS as it
requires
46 matches
Mail list logo
