Created attachment 330300 [details] my try on a HAVE_XAA_H patch - didn't try it yet X Server fails to start, "no screens defined" because trident_drv failed to load: [ 19712.297] (EE) Failed to load /usr/lib/xorg/modules/drivers/trident_drv.so: /usr/lib/xorg/modules/drivers/trident_drv.so: undefined symbol: TRIDENT_Sync as seen in Ubuntu, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/1044820 in comment #12, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/1044820/comments/12 -----cut----- xserver-xorg-video-trident (1:1.3.6-0ubuntu2) quantal; urgency=low * fix-loading.diff: Move TRIDENT_Sync inside #ifdef HAVE_XAA_H. Allows the driver to load. (LP: #1044820) -- Timo Aaltonen <email address hidden> Wed, 26 Sep 2012 11:02:15 +0300 -----cut-----
How do I include a patch in a local ebuild/package?
See the following information on how to patch this in a local overlay http://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/epatch/index.html http://devmanual.gentoo.org/ebuild-writing/misc-files/patches/index.html http://devmanual.gentoo.org/ebuild-writing/variables/index.html The first URL specifies how to patch from the ebuild, the second URL shows you how and where to place the patches whereas the third URL shows you what any of the variables you come across expand to. Of course, if there is an epatch_user call present in the ebuild you might as well just place the patch in /etc/portage/patches/CATEGORY/PACKAGE/ where you replace CATEGORY/PACKAGE
I patched the source by using Ctrl-Z to suspend the emerge process. Now I got a blank screen (not even the "X crashed" message is displayed properly) and the following on stderr: X: /var/tmp/portage/x11-base/xorg-server-1.13.0-r1/work/xorg-server-1.13.0/dix/pixmap.c:112: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (captured from a modified /etc/init.d/xdm script that calls strace right after starting the display manager, it's start method ends in /etc/X11/startDM.sh strace -ff -F -o /tmp/strace-gdm -p $(< "${PIDFILE}") eend 0 ) and in Xorg.0.log there is a line about an illegal opcode: [ 36347.242] (II) Module "ddc" already built-in [ 36347.243] f000:388c: 01 ILLEGAL EXTENDED X86 OPCODE! [ 36347.243] (II) TRIDENT(0): VESA VBE DDC not supported However, I'll stick to xorg-server-1.12 for now, maybe continue patching on sunday.
Today I sold the laptop that has the trident chip in it. However, yesterday I created an overlay, a patch file and patched binary package in the VirtualBox vm that I used to set up that old laptop (which I still have runnable, but due to the lack of another live eth device, eth0 is down and so the vm is currently unreachable...). I will upload those overlay files when I purchased a switch or eth-loopback plug. The result of testing the patched binary package on the trident (Toshiba Satellite Pro 6000) laptop was: a black screen, not even GDM's "X Server not running" dialog showed up (though, IIRC, the process list via ssh showed those). I still have strace files from the manual patching (using Ctrl-Z when emerging xf86-video-trident and patching the sources with the attached patch file) that led to a well-looking Xorg.0.log and the stderr message: write(2, "X: /var/tmp/portage/x11-base/xorg-server-1.13.0-r1/work/xorg-server-1.13.0/dix/pixmap.c:112: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed.\n", 158) = 158 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5c80000 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(16860, 16860, SIGABRT) = 0 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=16860, si_uid=0} --- +++ killed by SIGABRT +++ strace-gdm.16860 lines 2312-2353/2353 (END) If anyone is interested in that strace file (running X on a trident CyberBlade XPAi1 laptop) I will upload it here.
To me this looks like a developer has to have a look on trident_dga.c. What's the process to get this reported upstream - is there someone that has a machine with a trident chip in it? Kind regards, mdb
(In reply to comment #5) > What's the process to get this reported upstream - is there someone that has > a machine with a trident chip in it? Use the homepage listed in the ebuild: > Homepage: http://xorg.freedesktop.org/ Find a bug reporting site there (they have Bugzilla) and report it in the right category and product, provide enough details there and for tracking purposes you can then link the downstream and upstream bugs to each other. Please leave a link to the upstream bug here.
in Xorg Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57996
Created attachment 331768 [details] local overlay with patch for trident_dga.c, compiles and loads in Xorg to use the patch, have PORTDIR_OVERLAY=/usr/local/portage in /etc/(portage/)make.conf. Keep in mind that the result is a black screen and (on X's stderr): AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. However, maybe someone can go on from there on.
I applied the patch in 1.3.6-r1. The black screen issue is likely a different bug in ShadowFB code, which doesn't manifest on earlier xorg-server because the driver defaults to XAA there.
Sorry for my ignorance on this topic, but that comment seems to suggest that a workaround for the black screen might be to enable XAA in the trident driver. Or do I totally misunderstand the situation?
(In reply to comment #10) > Sorry for my ignorance on this topic, but that comment seems to suggest that > a workaround for the black screen might be to enable XAA in the trident > driver. Or do I totally misunderstand the situation? That's right. But XAA was removed from X Server 1.13, so it's not an option there.
I don't have any xaa Header files on my i686 Virtual Machine (which is the source of binpkgs for my former old-and-slow laptop with trident graphics) so I guess automake/configure/whatever is right with #undef HAVE_XAA_H. BTW there, xorg-server-1.13.0-r1 is masked because it doesn't work yet with xf86-video-trident... On the real hardware (a x86_64 Gentoo Linux) I have a file named /usr/include/xorg/xaarop.h which belongs to x11-base/xorg-server-1.13.0-r1. However, this is not xaa.h -- and I don't believe this is due to the different cpu architectures, i686 vs x86_64, until sb proves sth different... lapms-vb ~ # find / -xdev -path '*/include/*' -name '*xaa*.h' /usr/include/xorg/xaarop.h lapms-vb ~ #
xf86-video-trident should be keyworded ~amd64 ~ppc ~x86 since it simply doesn't work. Most likely it was never used on those platforms, maybe compiled...
(In reply to comment #13) > xf86-video-trident should be keyworded ~amd64 ~ppc ~x86 since it simply > doesn't work. > Most likely it was never used on those platforms, maybe compiled... It does work on X Server 1.12, doesn't it?
Yes, it worked on x11-base/xorg-server-1.12.4 with x11-drivers/xf86-video-trident-1.3.5, x11-drivers/xf86-input-keyboard-1.6.1, x11-drivers/xf86-input-mouse-1.7.2 and x11-drivers/xf86-input-evdev-2.7.0.
(In reply to comment #13) > xf86-video-trident should be keyworded ~amd64 ~ppc ~x86 since it simply > doesn't work. > Most likely it was never used on those platforms, maybe compiled... amd64 & ppc I am not sure, it is impossible to tell what kind of PC a user might put a video card in. But I have two x86 laptops with trident chips that work under 1.12, so I am not sure why you would suggest keywording trident. That is not going to make things stable for someone with trident video. Maybe having trident depend on <x11-base/xorg-server-1.13, but last I knew, portage did not deal well with those kinds of back and forth dependancies. I know this bug is closed with the original bug being fixed, but if I use EXA, X starts ok, but goes black on exit with a dead keyboard as opposed to going black on startup. I shall add this info to a more appropriate bug when I have more time. Option "AccelMethod" "EXA"
Ok yea, I added "<=x11-base/xorg-server-1.13" to the RDEPEND= of the unmasked x11-drivers/xf86-video-trident/xf86-video-trident-1.3.6.ebuild and it worked beautifully, giving me a warning that it was skipping the upgrade to xorg-server-1.13.... ebuild RDEP: https://bugs.gentoo.org/show_bug.cgi?id=449112 upstream EXA bug: https://bugs.freedesktop.org/show_bug.cgi?id=58841
