r128 DRI driver now fully functional on PPC

I've just committed the last of the updates required to get full hardware
accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks to Paul
Mackerras for allowing me to hack away on his machine over the last week!

The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
repository.  Please feel free to check it out and report any problems you have.

Now all we need is a PPC Linux build of Q3A...

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

I've just committed the last of the updates required to get full hardware
accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks
to Paul
Mackerras for allowing me to hack away on his machine over the last week!

The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
repository.  Please feel free to check it out and report any problems you
have.

I've done a first try and encountered a show-stopper (on this machine).
The machine is a PowerBook G3 with a r128 M3 (mobility), 8Mb video mem.
The issues are:

 - DRI support works only in 16 and 24/32 bits. However, 16 bits is
broken with UseFBDev and I can't use it without fbdev (see below). The
colors are screwed up (but the server works. I didn't yet try 3D since I
have not yet compiled a GL app to test with). 15 bits works fine with the
kernel driver but it's unuspported for DRI.
I beleive the aty128fb kernel driver need to be fixed for 16 bits.

 - I can't use 32 bits (it needs 9.4Mb of VRAM, I have only 8)

 - If I try to use the r128 driver without UseFBDev, the ATI chip locks
up (the LCD loose sync, the machine is hard locked up). This used to work
with earlier 4.0.1 servers, we need to figure out what changed. That
match what other people already noticed.

I'll do some tests with the broken 16 bits mode to see if I get 3D
working properly. I'll then see if I can figure out what cause the chip
to lockup without UseFBDev.

Except for those (minor hopefully) issues, its a nice work ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Benjamin Herrenschmidt wrote:

quoted

I've just committed the last of the updates required to get full hardware
accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many thanks
to Paul
Mackerras for allowing me to hack away on his machine over the last week!

The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
repository.  Please feel free to check it out and report any problems you
have.

I've done a first try and encountered a show-stopper (on this machine).
The machine is a PowerBook G3 with a r128 M3 (mobility), 8Mb video mem.
The issues are:

 - DRI support works only in 16 and 24/32 bits. However, 16 bits is
broken with UseFBDev and I can't use it without fbdev (see below). The
colors are screwed up (but the server works. I didn't yet try 3D since I
have not yet compiled a GL app to test with). 15 bits works fine with the
kernel driver but it's unuspported for DRI.
I beleive the aty128fb kernel driver need to be fixed for 16 bits.

I fixed this ages ago (screwed up colors and 16 bit support).
Read the README for details. thanks.

--
Andreas Hundt                              andi@convergence.de
Convergence Integrated Media GmbH          http://www.convergence.de
Rosenthaler Str. 51                        fon: +49(0)30-72 62 06 50
D-10178 Berlin                             fax: +49(0)30-72 62 06 55

On Wed, 31 Jan 2001, Benjamin Herrenschmidt wrote:

I'll do some tests with the broken 16 bits mode to see if I get 3D
working properly. I'll then see if I can figure out what cause the chip
to lockup without UseFBDev.

After a quick look i noticed that R128EnterVTFBDev/R128LeaveVTFBDev have to
enable/disable DRI just as R128EnterVT/R128LeaveVT. So dont try to switch to
console until its fixed while you use UseFBDev and DRI.

Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Benjamin Herrenschmidt wrote:

 - DRI support works only in 16 and 24/32 bits. However, 16 bits is
broken with UseFBDev and I can't use it without fbdev (see below). The
colors are screwed up (but the server works. I didn't yet try 3D since I
have not yet compiled a GL app to test with). 15 bits works fine with the
kernel driver but it's unuspported for DRI.
I beleive the aty128fb kernel driver need to be fixed for 16 bits.

Indeed. (More on that in another post from me) But even if it was fixed, I'm
afraid the DRI won't work with UseFBDev - it messed up the display (even more
;) when I tried. Some strange interaction between aty128fb and DRI I guess.

 - If I try to use the r128 driver without UseFBDev, the ATI chip locks
up (the LCD loose sync, the machine is hard locked up). This used to work
with earlier 4.0.1 servers, we need to figure out what changed. That
match what other people already noticed.

The server works for me without UseFBDev but with Option "ProgramFPRegs" "No".

We need to look at the changes to the flat panel code shortly before 4.0.2 .


Beware that I have other problems with my Pismo; windowed GL apps lock up
sooner rather than later. Fullscreen stuff works great. Even Intel users with
Mobility chips reported such problems on the Xpert list; I'm curious how it
fares on desktop machines.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Andreas Hundt wrote:

- driver now supports RGB565 16-bit mode

Looks like you killed RGB555 instead? I have another patch which makes both
available, but I never got the colors right in 565. I'll try to merge my patch
into yours and re-post it here and to Brad Douglas.

- pannig works now, allows correct dublebuffering, without jittering screen.

- FB_ACTIVATE_NOW and FB_ACTIVATE_VBL are now supported, CRTC_OFFSET_CNTL
  register is set correctly. aty128fb only accepted FB_ACTIVATE_NOW before
  but acted always like FB_ACTIVATE_VBL.
  This fix eliminates flickering in ClanLib (and other fbdev applications)
  when using doublebuffering.

- no more messed up colors in modes > 8 bpp. driver no longer uses hardware
  palette in modes > 8bpp, sets fbcon palette correctly instead.

Sounds great!


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 31 Jan 2001, Michel Dänzer wrote:

quoted

- no more messed up colors in modes > 8 bpp. driver no longer uses hardware
  palette in modes > 8bpp, sets fbcon palette correctly instead.

Sounds great!

The disadvantage is that if you change the palette, the text colors don't
change until you redraw the screen (or switch VC back-and-forth). That's why I
decided to use the hardware palette in directcolor modes.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Geert Uytterhoeven wrote:

On Wed, 31 Jan 2001, Michel Dänzer wrote:

quoted

quoted

- no more messed up colors in modes > 8 bpp. driver no longer uses
  hardware palette in modes > 8bpp, sets fbcon palette correctly
  instead.

Sounds great!

The disadvantage is that if you change the palette, the text colors don't
change until you redraw the screen (or switch VC back-and-forth). That's why
I decided to use the hardware palette in directcolor modes.

I don't mind using the hardware palette if you (or anyone) tell me how to get
RGB565 working with that. :)


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

The disadvantage is that if you change the palette, the text colors don't
change until you redraw the screen (or switch VC back-and-forth). That's why I
decided to use the hardware palette in directcolor modes.

I dont think it is good to use a palette in >8bpp modes. At least it
breaks
my fbdev software.

--
Andreas Hundt                              andi@convergence.de
Convergence Integrated Media GmbH          http://www.convergence.de
Rosenthaler Str. 51                        fon: +49(0)30-72 62 06 50
D-10178 Berlin                             fax: +49(0)30-72 62 06 55

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 7:08 PM +1100 1/30/01, Gareth Hughes wrote:

I've just committed the last of the updates required to get full hardware
accelerated 3D rendering with the ATI Rage 128 on PowerPC.  Many
thanks to Paul
Mackerras for allowing me to hack away on his machine over the last week!

The code is available on the ati-pcigart-0-0-1-branch in the DRI CVS
repository.  Please feel free to check it out and report any
problems you have.

Gareth (& everybody on the ppc dev list),

I've been trying to get this to work on a B&W G3 with a 100 MHz R128
PCI OEM card.

I'm getting things to build OK, but I did experience a couple
problems along the way.  The first was an old distribution /
compiler; when compiled by it, the X server would crash during
startup.  Reinstalling with LinuxPPC 2000 Q4 cured that.

The second is that the DRM kernel modules fail to build against the
2.2.18 headers.  A function in vm.c (I think) tries to access a field
named 'virtual' in struct page, which simply isn't there in 2.2.18.
The #if statements surrounding the code seem to be deliberately
compiling it only if the kernel is a 2.2 series, so I'm not sure what
is going on.  So I shifted over to the PPC 2.4 BK kernels and got
everything to build OK that way.

Where I'm at now is that the X server loads and runs (quite well I
might add), automatically loads the r128.o kernel module, and (in the
logfile) claims to have enabled direct rendering.  However, both
windowed and fullscreen GL apps are very clearly not being
accelerated.  Frame rates are obviously software renderer type frame
rates, and apps which check for multitexture capability complain that
it isn't there.

Any suggestions?  If anybody wants to see some logs from the server
starting up, I'll supply 'em.  Also, if anybody out there has gotten
this working, could you send me your XF86Config so I can make sure I
didn't do something silly to mine?

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

"Timothy A. Seufert" wrote:

The second is that the DRM kernel modules fail to build against the
2.2.18 headers.  A function in vm.c (I think) tries to access a field
named 'virtual' in struct page, which simply isn't there in 2.2.18.
The #if statements surrounding the code seem to be deliberately
compiling it only if the kernel is a 2.2 series, so I'm not sure what
is going on.  So I shifted over to the PPC 2.4 BK kernels and got
everything to build OK that way.

2.2 was never really well supported.  We've been using 2.4 for a long
time...

Where I'm at now is that the X server loads and runs (quite well I
might add), automatically loads the r128.o kernel module, and (in the
logfile) claims to have enabled direct rendering.  However, both
windowed and fullscreen GL apps are very clearly not being
accelerated.  Frame rates are obviously software renderer type frame
rates, and apps which check for multitexture capability complain that
it isn't there.

Any suggestions?  If anybody wants to see some logs from the server
starting up, I'll supply 'em.  Also, if anybody out there has gotten
this working, could you send me your XF86Config so I can make sure I
didn't do something silly to mine?

Run with LIBGL_DEBUG=1 and see what it says.  Also, try the glxinfo
program (available from the DRI resources page) or Mesa/demos/glinfo --
these print out information about the OpenGL library being used.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

"Timothy A. Seufert" wrote:

Any suggestions?  If anybody wants to see some logs from the server
starting up, I'll supply 'em.  Also, if anybody out there has gotten
this working, could you send me your XF86Config so I can make sure I
didn't do something silly to mine?

http://n.ethz.ch/student/daenzerm/download/DRI/XF86Config

is what I use on my Pismo.


Beware that I have merged in locally some fixes from the trunk which seem to
help for some problems I had - Gareth, will we merge the branch into the trunk
anytime soon or should I commit those to the branch?

The only issues I'm seeing now are broken lighting textures in quake-gl,
missing texture in xtraceroute and garbage at the top of the framebuffer
periodically. The last also causes a delay so I suspect it's some DMA
operation going wrong and the driver hitting a timeout, unfortunately I don't
have time to track it down and probably won't have for weeks. :(

Otherwise it works great for me!


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michel Dänzer wrote:

Beware that I have merged in locally some fixes from the trunk which seem to
help for some problems I had - Gareth, will we merge the branch into the trunk
anytime soon or should I commit those to the branch?

Jeff Hartmann has informed me he'll be merging it in RSN.

The only issues I'm seeing now are broken lighting textures in quake-gl,
missing texture in xtraceroute and garbage at the top of the framebuffer
periodically. The last also causes a delay so I suspect it's some DMA
operation going wrong and the driver hitting a timeout, unfortunately I don't
have time to track it down and probably won't have for weeks. :(

Once we get everything on the trunk, we should look into these more.
There may already be fixes on the trunk for these problems -- the branch
was created a while ago now.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Gareth Hughes wrote:

Michel Dänzer wrote:

quoted

Beware that I have merged in locally some fixes from the trunk which seem
to help for some problems I had - Gareth, will we merge the branch into
the trunk anytime soon or should I commit those to the branch?

Jeff Hartmann has informed me he'll be merging it in RSN.

Cool. I assume it won't get into an XFree86 release before 4.1.0 though?

quoted

The only issues I'm seeing now are broken lighting textures in quake-gl,
missing texture in xtraceroute and garbage at the top of the framebuffer
periodically. The last also causes a delay so I suspect it's some DMA
operation going wrong and the driver hitting a timeout, unfortunately I
don't have time to track it down and probably won't have for weeks. :(

Once we get everything on the trunk, we should look into these more.
There may already be fixes on the trunk for these problems -- the branch
was created a while ago now.

Looking forward to that - I'd expect the first one to be an endianness
leftover though, and the second one might even be a client issue.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:

Run with LIBGL_DEBUG=1 and see what it says.

This revealed what was happening.

I set the project root to /usr/Xgart to avoid having to overwrite my
existing X11 installation.  libGL was trying to load r128_dri.so, but
it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
exist.

Since then, I've been trying a number of things, with partial success:


1. Tried to replace /usr/X11R6/lib in /etc/ld.so.conf with
/usr/Xgart/lib.  Result: X server won't start because the DRI tree
isn't building most of the various X shared libraries like Xmu, ICE,
etc.


2. Tried to work around #1 by leaving both /usr/Xgart/lib and
/usr/X11R6/lib in ld.so.conf (Xgart first so it gets priority).

Result: 3D acceleration works!  However, there are a couple major
problems.  First, window titles aren't drawn (the borders are, but
the title text is not), and second, upon running a GL program (I've
been using gears and gloss from Mesa 3.3), I lose keyboard and mouse
input.  Sometimes the mouse cursor is still visible, but clicks do
nothing.  Even pressing caps lock doesn't toggle the capslock light.
I have to telnet into the machine and kill the GL program to get
control back.


3. As an alternate to #2, I went back to just /usr/X11R6/lib in
ld.so.conf, and added symlinks under /usr/X11R6/lib to the missing GL
and DRI libs in the Xgart tree.  I got the window titles back this
way (must be a busted non-3D library somewhere in the DRI tree
causing that), but the input device problems persist.


4. Tried to do the right thing by figuring out how to build the
missing libraries in the DRI tree.  The source code for all the
relevant libs seems to be there, but I can't decipher the X11 build
system enough to figure out exactly why they aren't being built.

I think it's the "#define BuildServersOnly YES" line in host.def, but
commenting it out breaks the build because the DRI tree is not a full
XFree86 source tree.


I'm guessing that this is really the way to go.  Does anybody know of
a way to force building more of the libraries without actually
building everything?  Or do I need to download the remaining chunks
of the Xfree86 source tree and do a full build of everything?

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

"Timothy A. Seufert" wrote:

At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:

quoted

Run with LIBGL_DEBUG=1 and see what it says.

This revealed what was happening.

I set the project root to /usr/Xgart to avoid having to overwrite my
existing X11 installation.  libGL was trying to load r128_dri.so, but
it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
exist.

Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it didn't
pick up the right libGL.

Since then, I've been trying a number of things, with partial success:

1. Tried to replace /usr/X11R6/lib in /etc/ld.so.conf with
/usr/Xgart/lib.  Result: X server won't start because the DRI tree
isn't building most of the various X shared libraries like Xmu, ICE,
etc.

2. Tried to work around #1 by leaving both /usr/Xgart/lib and
/usr/X11R6/lib in ld.so.conf (Xgart first so it gets priority).

Result: 3D acceleration works!  However, there are a couple major
problems.  First, window titles aren't drawn (the borders are, but
the title text is not), and second, upon running a GL program (I've
been using gears and gloss from Mesa 3.3), I lose keyboard and mouse
input.  Sometimes the mouse cursor is still visible, but clicks do
nothing.  Even pressing caps lock doesn't toggle the capslock light.
I have to telnet into the machine and kill the GL program to get
control back.

What's your hardware? Jack Howarth used to have similar problems with the old
driver, but AFAIR it was because he tried to build things with the Red Hat
following the Red Hat procedure.

3. As an alternate to #2, I went back to just /usr/X11R6/lib in
ld.so.conf, and added symlinks under /usr/X11R6/lib to the missing GL
and DRI libs in the Xgart tree.  I got the window titles back this
way (must be a busted non-3D library somewhere in the DRI tree
causing that), but the input device problems persist.

4. Tried to do the right thing by figuring out how to build the
missing libraries in the DRI tree.  The source code for all the
relevant libs seems to be there, but I can't decipher the X11 build
system enough to figure out exactly why they aren't being built.

I think it's the "#define BuildServersOnly YES" line in host.def, but
commenting it out breaks the build because the DRI tree is not a full
XFree86 source tree.

I'm guessing that this is really the way to go.  Does anybody know of
a way to force building more of the libraries without actually
building everything?  Or do I need to download the remaining chunks
of the Xfree86 source tree and do a full build of everything?

I wouldn't waste too much time to figure that out (if it works at all) because
this will eventually be in the standard XFree86. For now, I use a symlink for
r128_dri.so and set LD_LIBRARY_PATH.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michel Dänzer wrote:

"Timothy A. Seufert" wrote:

quoted

At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:

quoted

Run with LIBGL_DEBUG=1 and see what it says.

This revealed what was happening.

I set the project root to /usr/Xgart to avoid having to overwrite my
existing X11 installation.  libGL was trying to load r128_dri.so, but
it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
exist.

Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it didn't
pick up the right libGL.

I'd say libGL.so is doing dlopen( "modules/dri/r128_dri.so", ... ) and
thus picking up the first instance of that in the dynamic loader's
path.  Similarly, applications linked with -lGL will pick up the first
instance of libGL.so, not necessarily the one residing under the current
X server's ProjectRoot directory.

It's very important you have ld.so.conf set to pick up the correct
version if you haven't installed the DRI-enabled X server in /usr/X11R6.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Gareth Hughes wrote:

Michel Dänzer wrote:

quoted

"Timothy A. Seufert" wrote:

quoted

At 9:02 PM +1100 2/23/01, Gareth Hughes wrote:

quoted

Run with LIBGL_DEBUG=1 and see what it says.

This revealed what was happening.

I set the project root to /usr/Xgart to avoid having to overwrite my
existing X11 installation.  libGL was trying to load r128_dri.so, but
it was looking under /usr/X11R6/lib/modules/dri, which doesn't even
exist.

Strange, it should look in <ProjectRoot>/lib/modules/dri/ . Seems it
didn't pick up the right libGL.

I'd say libGL.so is doing dlopen( "modules/dri/r128_dri.so", ... ) and
thus picking up the first instance of that in the dynamic loader's
path.  Similarly, applications linked with -lGL will pick up the first
instance of libGL.so, not necessarily the one residing under the current
X server's ProjectRoot directory.

First I thought I'd stand corrected, but on second thought - it looks for
/usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
/usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
there if I set LD_LIBRARY_PATH to the exports/lib directory in the build tree.


Am I still not getting it? :)


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michel Dänzer wrote:

First I thought I'd stand corrected, but on second thought - it looks for
/usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
/usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
there if I set LD_LIBRARY_PATH to the exports/lib directory in the build tree.

Am I still not getting it? :)

Sorry, my mistake.  libGL.so opens $MODULEDIR/dri/r128_dri.so, where
$MODULEDIR is defined by the Imakefiles (and would be
/usr/X11R6-DRI/lib/modules in your case).  So, the problem may be that
the wrong libGL.so is being picked up -- and this *is* an ld.so.conf
problem.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 9:28 PM +1100 2/26/01, Gareth Hughes wrote:

Michel Dänzer wrote:

quoted

 First I thought I'd stand corrected, but on second thought - it looks for
 /usr/X11R6-DRI/lib/modules/dri/r128_dri.so on my machine (if ProjectRoot is
 /usr/X11R6-DRI), but /usr/X11R6-DRI/lib isn't in ld.so.conf . It even looks
 there if I set LD_LIBRARY_PATH to the exports/lib directory in the
build tree.

 Am I still not getting it? :)

Sorry, my mistake.  libGL.so opens $MODULEDIR/dri/r128_dri.so, where
$MODULEDIR is defined by the Imakefiles (and would be
/usr/X11R6-DRI/lib/modules in your case).  So, the problem may be that
the wrong libGL.so is being picked up -- and this *is* an ld.so.conf
problem.

Could the Imakefiles have been broken by the following options in site.def?

#define NothingOutsideProjectRoot YES
#define EtcX11Directory ProjectRoot/etc

I enabled (uncommented) both of these since I thought it might be a
good idea to force X to be completely self-contained within
ProjectRoot.

I just tried a build without these options and it seems to clear up
the library problem.  After doing so I have only two differences from
the config files in CVS: I set ProjectRoot and disabled Glide3.  So
it's entirely possible that setting Nothing... and/or EtcX11Dir...
caused the compiled-in default library search path you describe to
get mangled.


I still have the problem with keyboard/mouse input being ignored once
a GL app starts.  A friend suggested disabling DGA, but that didn't
help.  I do notice this message popping in the system logs, repeated
numerous times:

[drm:drm_lock_take] *ERROR* 1 holds heavyweight lock

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

"Timothy A. Seufert" wrote:

I still have the problem with keyboard/mouse input being ignored once
a GL app starts.  A friend suggested disabling DGA, but that didn't
help.  I do notice this message popping in the system logs, repeated
numerous times:

[drm:drm_lock_take] *ERROR* 1 holds heavyweight lock

This happens when the lock ioctl occurs when the lock is already held.
'1' is the X server, so the X server is grabbing the lock when it
already has it.

-- Gareth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Gareth Hughes wrote:

"Timothy A. Seufert" wrote:

quoted

I still have the problem with keyboard/mouse input being ignored once
a GL app starts.  A friend suggested disabling DGA, but that didn't
help.  I do notice this message popping in the system logs, repeated
numerous times:

[drm:drm_lock_take] *ERROR* 1 holds heavyweight lock

This happens when the lock ioctl occurs when the lock is already held.
'1' is the X server, so the X server is grabbing the lock when it
already has it.

Which might be fixed by the attached patch which Gareth posted to dri-devel
lately.

But don't expect this to solve your input problems as I never had them.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member