Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
daenzer at debian.org
Wed Mar 9 05:18:24 PST 2011
On Mit, 2011-03-09 at 14:55 +0200, Apollon Oikonomopoulos wrote:
> On 13:39 Wed 09 Mar , Michel Dänzer wrote:
> > On Die, 2011-03-08 at 20:06 +0200, Apollon Oikonomopoulos wrote:
> > >
> > > I've been trying to bisect upstream between mesa_7_7_1 and mesa-7.8,
> > > without any success. A large part of the commit tree for r600 between
> > > 7.7.1 and 7.8 FTBFS with any debian libdrm-dev version I tried since
> > > 2.4.15-1, stating:
> > >
> > > In file included from radeon_common.h:4,
> > > from radeon_screen.c:49:
> > > radeon_common_context.h:405: error: array type has incomplete element type
> > >
> > > I've searched around a bit and this seems to be due to some libdrm API
> > > changes.
> > Can you provide a specific mesa commit hash where this happens?
> For example, a1b9c4e22a83d2125f66c3a3af3143bc0daee9a4 (2nd bisection
> step) and the whole area around it.
> For the record, the following mesa commits seem to make r600 conform to
> the new API:
> $ git log --oneline origin/master | grep "new libdrm_radeon api"
> bd9e0eb radeon/r600: use new libdrm_radeon api
> 9373287 radeon/r600: use new libdrm_radeon api
> b065aec radeon/r600: use new libdrm_radeon api
> (Basically the same commit on different branches)
> however, they are not cleanly backportable to the affected commits I
> Debian libdrm-dev versions prior to 2.4.18 do not ship
> /usr/include/drm/drm.h which is needed, and versions from 2.4.18
> (included) and onwards fail with the above message. Any hints as to the
> version of libdrm required to compile these revisions?
You could try an older version of libdrm-dev with /usr/include/drm/drm.h
manually copied from a newer version. It should be backwards compatible.
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg-driver-ati