[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
> great that you found the problem!
> > 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.
Main Index |
Thread Index |