[Openchrome-devel] pciaccess_branch and panels

[Xavier Bachelot]

Jon Nettleton wrote:
> On Sun, Mar 9, 2008 at 2:13 PM, Xavier Bachelot <xavier at bachelot.org> wrote:
>> Xavier Bachelot wrote:
>>  > Gabriel Mansi wrote:
>>  >> On Sat, 2008-03-08 at 18:50 +0100, Xavier Bachelot wrote:
>>  >>> Xavier Bachelot wrote:
>>  >>>> Jon Nettleton wrote:
>>  >>>>> On Fri, Mar 7, 2008 at 11:01 PM, Xavier Bachelot
>>  >>>>> <xavier at bachelot.org> wrote:
>>  >>>>>> Hi Jon and all,
>>  >>>>>>
>>  >>>>>>  I got a libpciaccess patch against 0.2.901 ready for review.
>>  >>>>>>  The memory detection bug is fixed (changeset 359).
>>  >>>>>>  I also fixed a typo (changeset 358).
>>  >>>>>>
>>  >>>>> Thanks Xavier,
>>  >>>>>
>>  >>>>> I am still having a minor typo problem with my EeePC.  But if
>>  >>>>> everything is working great then that is brilliant.
>>  >>>>>
>>  >>>> No it still doesn't work.
>>  >>>> I applied the below patch. When starting X, the last message in log
>>  >>>> is (II) CHROME(0): Step 1... so it seems something is wrong with the
>>  >>>> macros.
>>  >>>>
>>  >>>> RHBZ is https://bugzilla.redhat.com/show_bug.cgi?id=435907
>>  >>>> Last log is : https://bugzilla.redhat.com/attachment.cgi?id=297302
>>  >>>> SRPM is
>>  >>>> http://washington.kelkoo.net/epia/patches/xorg-x11-drv-openchrome-0.2.901-12.fc9.src.rpm
>>  >>>>
>>  >>> This error is thrown to the terminal :
>>  >>>
>>  >>> error setting MTRR (base = 0xd1000000, size=0x00009000, type= 1) Invalid
>>  >>> Argument (22)
>>  >>> X: symbol lockup error:
>>  >>> /usr/lib/xorg/modules/drivers//openchrome_drv.so:
>>  >>> undefinied symbol: SUBVENDOR_ID
>>  >>> giving up.
>>  >>>
>>  >> SUBVENDOR_ID is defined in via.h which is not included in via_id.c where
>>  >> is used.
>>  >> Try the attached patch.
>>  >>
>>  > Thx Gabriel.
>>  > Attached is the updated libpciaccess patch.
>>  >
>>  Ok, it's in a much better shape now, but video RAM size detection is
>>  busted at least for VM800 :
>>  https://bugzilla.redhat.com/process_bug.cgi#c22
>>
>>  For the record, I'm running my CLE266 and KM400 on 0.2.901 plus the
>>  libpciaccess patch on a non-libpciaccess enabled xserver. No sign of any
>>  regression so far...
>>
> 
> The videoram detection code is going to be a bit more work.  As spare
> cycles free up I will try and continue to poke it into shape.  We
> definitely want this all fixed up for the Fedora 9 release.
> 
> Jon
> 
Shall I just use the old memory detection path in Rawhide for now ? Even 
if it's not perfect, we need to ship something that works for F9 Beta.

Actually, I'm pursuing 2 goals, something that work out of the box for 
F9 Beta, even if it's hacky, and merge to trunk so we can get rid of the 
pciaccess branch. It seems the patch doesn't introduce any regression in 
the non libpciaccess code path, but I'd still like to have someone more 
skilled than me review it. trunk and pciaccess are diverging quite a bit 
at the moment and it's hard to maintain a patch.

Regards,
Xavier