The first patch (against the Mesa tree) fixes tdfx_screen.c to use the new
interface. The second patch (against the DRI tree) fixes the Imakefilery to
use the new interface and link against the common objects.
Without these two tdfx is completely broken. With them, it works as well as
it did
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> That's part of why I'm asking. From talking to Linus in the past, I
> know that merging in changes is a PITA due to our funky directory
> structure. I'd like to make that easier. :)
Part of the pain could be caused by the shared/linux split in the
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> >>When we do this move, we're open to the possibility of reorganizing the
> >>file structure. What can we do to make it easier for kernel release
> >>maintainers to merge changes into their trees?
> >
> > - Make sure that the files in the main kernel
Andrew Morton wrote:
Ian Romanick <[EMAIL PROTECTED]> wrote:
We're looking at reorganizing the way DRM drivers are maintained.
Currently, the DRM kernel code lives deep in a subdirectory of the DRI
tree (which is a partial copy of the XFree86 tree). We plan to move it
"up" to its own module at
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> Ian Romanick <[EMAIL PROTECTED]> wrote:
> >
> > We're looking at reorganizing the way DRM drivers are maintained.
> > Currently, the DRM kernel code lives deep in a subdirectory of the
> DRI
> > tree (which is a partial copy of the XFree86 tree). W
Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> We're looking at reorganizing the way DRM drivers are maintained.
> Currently, the DRM kernel code lives deep in a subdirectory of the DRI
> tree (which is a partial copy of the XFree86 tree). We plan to move it
> "up" to its own module at the top lev
We're looking at reorganizing the way DRM drivers are maintained.
Currently, the DRM kernel code lives deep in a subdirectory of the DRI
tree (which is a partial copy of the XFree86 tree). We plan to move it
"up" to its own module at the top level. That should make it *much*
easier for people
Em Seg 15 Mar 2004 18:44, you wrote:
> On Mon, 15 Mar 2004 17:30:48 -0300
>
> "Paulo R. Dallan" <[EMAIL PROTECTED]> wrote:
> > Em Ter 09 Mar 2004 20:09, you wrote:
> > > "Paulo R. Dallan" <[EMAIL PROTECTED]> wrote:
> > > > Em Seg 08 Mar 2004 13:31, you wrote:
> > > > > Em Seg 08 Mar 2004 08:35, you
Jon Smirl wrote:
Could someone with admin privs at fd.o please make a new project and put the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it does
> Thomas Hellström wrote:
>> Hi!
>>
>> Is it possible to use the heavyweight drm locking mechanisms for other
>> locks than the global hardware lock?
>>
>> What I'm after is a mechanism to suspend drm-aware processes until a
>> display resource gets available and then wake them up on a FIFO basis
>
On Mon, 2004-03-15 at 21:03, Keith Packard wrote:
> Around 8 o'clock on Mar 15, Jon Smirl wrote:
>
> > Could someone with admin privs at fd.o please make a new project
>
> It would surely be a lot easier to just create a new module in an existing
> project. I think the DRM fits reasonably well
Around 8 o'clock on Mar 15, Jon Smirl wrote:
> Could someone with admin privs at fd.o please make a new project
It would surely be a lot easier to just create a new module in an existing
project. I think the DRM fits reasonably well under the DRI banner.
-keith
pgp0.pgp
Description:
On Sul, 2004-03-14 at 20:00, Jon Smirl wrote:
> However, I am saying that we need a blend between framebuffer and DRM. Not DRM
> bolted on top of framebuffer.
You keep imposing policy in the mid layer. How do you know whether you
need a blend or not - its card specific. Some cards have 2D/3D sepe
On Llu, 2004-03-15 at 16:51, Ian Romanick wrote:
> Jon Smirl wrote:
>
> > 1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented
> > 2) VGA_ENABLE -- this is used to control the active VGA card in the system.
> > 3) BLANK - simple call to allow Vesa power management to blank
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PM PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IR
Jon Smirl wrote:
Could someone with admin privs at fd.o please make a new project and put the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it doesn
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> How does all this work on non-x86 systems? Since the rest of the world,
> thankfully, doesn't use compiled machine code in the on-card firmware,
> how is that handled? *Is* that handled? :)
The main purpose is to initialize secondary adapters that
Patrick Dohman wrote:
I have been able to reproduce several x server crashes by killing a
process from tty 1,2 or 3 that is running on tty5 this crash occurs
after killing a variety of process such as evolution and mozilla and
then attempting to switch to tty5 from tty 1,2 or 3. I am running
XFree
Could someone with admin privs at fd.o please make a new project and put the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it doesn't matter.
If yo
Jon Smirl wrote:
1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented
2) VGA_ENABLE -- this is used to control the active VGA card in the system.
3) BLANK - simple call to allow Vesa power management to blank the display.
How does all this work on non-x86 systems? Since th
Thomas Hellström wrote:
Hi!
Is it possible to use the heavyweight drm locking mechanisms for other
locks than the global hardware lock?
What I'm after is a mechanism to suspend drm-aware processes until a
display resource gets available and then wake them up on a FIFO basis when
the process that c
http://bugme.osdl.org/show_bug.cgi?id=1811
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|
On Mon, 15 Mar 2004 09:01:16 +
avilella <[EMAIL PROTECTED]> wrote:
> I've got no problem with savage-20040303-linux.i386.tar.bz2,
>
> Next step would be to have it working on 2.6:
>
> Should I be following the steps in install.sh? Which differences are
> there between 2.4 and 2.6 installatio
I've got no problem with savage-20040303-linux.i386.tar.bz2,
Next step would be to have it working on 2.6:
Should I be following the steps in install.sh? Which differences are
there between 2.4 and 2.6 installation of DRM and DRI stuff?
Thanks,
Albert.
On Fri, 2004-03-12 at 15:33, Alex De
Hi!
Is it possible to use the heavyweight drm locking mechanisms for other
locks than the global hardware lock?
What I'm after is a mechanism to suspend drm-aware processes until a
display resource gets available and then wake them up on a FIFO basis when
the process that currently holds the reso
Hi!
Yep, I had the same problems, trying to get the
TDFX/solo work.
Keith?
>I don't think they are necessary so the _SOLO defines
>could be extended. Keith wrote the code so I'm not
>sure what he intentions were.
>
>--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>>
>> The current miniglx fakes up
Michel Dänzer <[EMAIL PROTECTED]> writes:
> On Sun, 2004-03-14 at 21:00, Jon Smirl wrote:
> >
> > Linux's current design has lots of holes in it. Start two X servers on two
> > different VTs (not just two sessions to the same X server)
>
> How do you start two sessions to the same X server? *sh
Michel DÃnzer wrote:
On Sun, 2004-03-14 at 07:14, Jon Smirl wrote:
This is a first pass at the three new IOCTL patch.
It is against the DRM copy in the Mesa tree.
And exactly why does that still exist? I know you don't listen to me,
but I don't think you can ignore Keith.
If there's any reason
Jon Smirl wrote:
I don't think they are necessary so the _SOLO defines could be extended. Keith
wrote the code so I'm not sure what he intentions were.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
The current miniglx fakes up some DDX version numbers but these only work
for the radeon drivers, (4.0
29 matches
Mail list logo
