Port-luna68k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Xorg 1.20 1bpp server performance regression and possible fixes

mrg@ wrote:

> great that you found the problem!

Thanks :-)

> > 1) Revert the whole commit as is (and put back fbtile.c to SRCS.fb
> >    in src/external/mit/xorg/server/xorg-server/fb/Makefile.fb)
> > 
> > 2) Put back the "fbEvenTile" and old "fbTile" to switch
> >    "fbOddTile" (which is same as current fbTile) or "fbEvenTile"
> >    into existing fb/fbfill.c as inline functions, to make
> >    future import/merge less confusing
> > 
> > 3) Ask xorg upstream to revert the change
> > 
> > Of course the best way is 3) and 1), but I'm afread most people
> > don't think it's worth to keep and maintain extra code for obsolete
> > monochrome (and some 8bpp) servers and retro-computing geeks.
> i don't have a particular opinion about #1 or #1 so please
> do what you feel is best.

(I guess you meant #1 or #2 here)
Ok, I'll commit as #1 (reverting changes) soon and send a pullup
request to netbsd-9.

> #3 should be done.

I'll also send an issue to upstream gitlab.

> i am not sure who your hesitation came from,

There are two concerns.

First, it seems upstream xorg has tried to get rid of legacy code:

 >> Remove support for old Sun Type_4/5 keyboards
 (In the perfect world we should resurrect this and abandon sunKeyMap.c)

 >> fb: Remove even/odd stipple slow-pathing
 (Though this seems to cause no visible regressions)

Second, just I'm not familiar with cvs(1) and I wonder what will
happen on the future import if files removed in the vendor branch
are resurrected in HEAD. Furthermore, we also have to maintain
src/external/mit/xorg/server/xorg-server/fb/Makefile.fb to keep
additional local files.

If you (and other people) don't mind to keep these manipulations,
#2 is not necessary.

Izumi Tsutsui

Home | Main Index | Thread Index | Old Index