x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/drm -I/usr/include/X11/dri -I../../src -DTRUE=1 -DFALSE=0 -march=k8 -O2 -pipe -Wall -MT viaLowLevel.lo -MD -MP -MF .deps/viaLowLevel.Tpo -c viaLowLevel.c -fPIC -DPIC -o .libs/viaLowLevel.o In file included from ../../src/via_drmclient.h:27, from /usr/include/drm/via_drm.h:36, from ../../src/via_xvmc.h:29, from viaXvMCPriv.h:35, from viaLowLevel.c:34: /usr/include/drm/drm.h:567: error: expected specifier-qualifier-list before 'uint32_t' make[3]: *** [viaLowLevel.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/x11-drivers/xf86-video-via-0.2.2/work/xf86-video-via-0.2.2/src/xvmc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-drivers/xf86-video-via-0.2.2/work/xf86-video-via-0.2.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-drivers/xf86-video-via-0.2.2/work/xf86-video-via-0.2.2' make: *** [all] Error 2 * * ERROR: x11-drivers/xf86-video-via-0.2.2 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3006: Called x-modular_src_compile * environment, line 3776: Called x-modular_src_make * environment, line 3812: Called die * The specific snippet of code: * emake || die "emake failed" * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/x11-drivers/xf86-video-via-0.2.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/xf86-video-via-0.2.2/temp/environment'. * Reproducible: Always Steps to Reproduce: I think it's due to (fresh for me) new xorg-server-1.5.0. The /usr/include/drm/drm.h does not include the correct header (stdint.h) to allow uint32_t to be defined on its declaration. As those packages (libdrm and xf86-video-via) are rather old i suspect that a header was previously included by xorg-server and is no longer included. A simple way to patch this could be to move (in viaLowLevel.c) #if HAVE_INTTYPES_H # include <inttypes.h> #else # ifndef uint32_t # define uint32_t CARD32 # endif #endif before including faulty drm.h Running x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/drm -I/usr/include/X11/dri -I../../src -DTRUE=1 -DFALSE=0 -march=k8 -O2 -pipe -Wall -MT viaLowLevel.lo -MD -MP -MF .deps/viaLowLevel.Tpo -c viaLowLevel.c -fPIC -DPIC -E | vim - shows that uint32_t is declared from "/usr/include/xf86drm.h" (i.e. later that drm.h). I someone with "old" xorg-server could check who included this <stdint.h> in order maybe to fix this bug in via driver or maybe even in libdrm I put this bug as major for those who can't have openchrome replacement for their video card driver.
Created attachment 166777 [details] emerge --info
(In reply to comment #0) > I put this bug as major for those who can't have openchrome replacement for > their video card driver. Thanks for mentioning the openchrome driver. I've overcome the uint32_t problem by a quick and dirty hack directly to /usr/include/drm/drm.g, only to get complains about another unknown type, pciVideoPtr. Having then googled http://www.x.org/wiki/PciReworkHowto I've realized that what I really need to compile with upgraded X server and libraries is a new version of the video driver -- or a non-trivial patch. Looking if anybody has made that patch or if I'll have to write it myself, I've found this bug. Currently I am upgrading the system at my notebook, and unfortunately the openchrome driver does not seem to work for me yet (perhaps there lasts some package that needs upgrade or recompilation, perhaps I'll have to change more of my /etc/X11/xorg.conf than the video driver from via to openchrome), but x11-base/xorg-server looks like no version, except 1.3.0.0-r4, depends on x11-drivers/xf86-video-via anymore, all the newer versions use either openchrome or vesa only for VIA cards anyway.
I was able to emerge xf86-video-via by downgrading libdrm from 2.3.1 to 2.3.0 and re-emerging xf86-video-via. i.e. emerge =x11-libs/libdrm-2.3.0 emerge xf86-video-via # emerges the 0.2.2 version
Created attachment 169088 [details] x11-drivers/xf86-video-unichrome-9999.ebuild An ebuild of the git version of the unichrome.sourceforge.net driver that builds, but does not work at the time beeing.
(In reply to comment #3) > I was able to emerge xf86-video-via by downgrading libdrm from 2.3.1 to 2.3.0 > and re-emerging xf86-video-via. I hope that won't be the only possible solution in the long time prospect. I'm affraid that keeping libdrm at 2.3.0 version blocks multiple X-related upgrades already. At the same time, I probably should either hope in a fortunate future upgrade or try downgradind deeply, because anout a year ago my laptop used to hibernate to disk well, but now my X-server is unable to wake up properly. I've tried the openchrome driver only to find it freezing my laptop panel completely. Even building it from svn sources did not help. I've looked at the unichrome driver form http://unichrome.sourceforge.net too, and that may look he most promissing: the last release is quite old, and does not compile, but the git sources compiled well -- only the driver then rejected all the video modes it came across, complaining about refresh frequencies being out of range. Finally I've tried to pull the GIT sources of the Xorg via driver, but thus I've just confirmed it's apparently abandoned and unmaintained now. Looks like the Xorg driver belongs to the past and won't ever evolve. Freezing the system at a particular past versions set may work, but I fear problems with possibly desireable upgrades of very far related or even seemingly unrelated packages, as well as with the old ebuilds dying out slowly from the portage tree, thus becoming unavailable for eventual recompilations; those installed are preserved in /var/db/pkg, but some time some dependency yet uninstalled might become needed. Moreover, for me, due to problems brought about by some past upgrade, extensive downgrading and digging up obsolete versions might be necessary. So I hope into openchrome or unichrome becoming usable soon. Comparing the sources of the three drivers and patching one of them might help, but I postpone any attempt on that for now. That task might easily exceed my abilities or at least the time I can use for it.
(In reply to comment #3) > I was able to emerge xf86-video-via by downgrading libdrm from 2.3.1 to 2.3.0 > and re-emerging xf86-video-via. What happens if you add #include <stdint.h> to libdrm-2.3.1's /usr/include/drm/drm.h for testing? For example right after #define _DRM_H_
Oh, sorry, I didn't read the comments carefully. What I'm proposing is the same hack as in comment #2 - except it's not a hack, it's the correct thing to do upstream if the uncondtional use of uint32_t in a struct below is intentional
Created attachment 169912 [details, diff] xf86-video-via-0.2.2-libpciaccess.patch An attempt to patch the last release of x11-drivers/xf86-video-via for libpciaccess. Copied mostly mechanically from x11-drivers/xf86-video-openchrome. Compiles, but DOES NOT WORK FOR ME. Actually breaks my stuff even worse then the openchrome does.
Created attachment 169913 [details] xf86-video-via-0.2.2-r1.ebuild An ebuild applying xf86-video-via-0.2.2-libpciaccess.patch DOES NOT WORK FOR ME. Use at your own risk for experiments, if you will. I'm giving up there, at least for now. Going to compile the latest and greatest kernel, upgrade everything (what of my problem is in a kernel driver, MESA driver or the libpciacess?), and if X and openchrome do not work for me then (at my VIA K8N800 laptop), I'll start masking and downgrading.
*** Bug 248533 has been marked as a duplicate of this bug. ***
Created attachment 180525 [details] xf86-video-openchrome-9999.ebuild An SVN ebuild for x11-drivers/xf86-video-openchrome I use to periodically update the latest code. Finally works for me, allowing me to abandon x11-drivers/xf86-video-via and avoid extensive downgrading. May be the latest code even is unnecessary, what made my setup work was the change of the relevant xorg.conf section to: Section "Device" Identifier "VIA" Driver "openchrome" Option "ActiveDevice" "DFP, TV" Option "TVType" "PAL" Option "TVOutput" "S-Video" Option "AccelMethod" "EXA" Option "EnableAGPDMA" "true" Option "DisableIRQ" "true" Option "MigrationHeuristic" "greedy" Option "NoXVDMA" "true" EndSection That has involved cleanup and adaptation to the parameter set and names documented in the openchrome manpage. Apparently what used to break my setup was something in the old parameter set, or something missing there, though I don't know what was the exact cause.
In the portage there is also x11-drivers/xf86-video-openchrome-0.2.903 available which seems to compile fine with xorg-server-1.5.3-r5
Since the driver does not compile properly with current libdrm-2.4.5 or even with libdrm-2.3.1 shouldn't it be removed from the stable branch and replaced with an ebuild that requires libdrm-2.3.0 explicitly ? I also think that it should be available only on the testing branch... Keeping it in stable will only bring more problems for users
I even suspect that this driver http://www.x.org/wiki/via is dead (the link to its sources being broken). Same goes for the Unichrome driver http://unichrome.sourceforge.net/ -- last news http://sourceforge.net/forum/forum.php?forum_id=561166 being from April 2006 and the git repository link there broken. Looks like the only driver for VIA graphics now is the Openchrome one, there is probably no need to keep the other two in the portage tree at all any longer.
The sources from http://linux.via.com.tw/ (http://linux.via.com.tw/support/beginDownload.action?eleid=263&fid=504) haven't been updated since December 2008, but they do seem to be live. (Maybe http://www.x.org/wiki/via is outdated?)
I'm running into this problem too, I will probably see if I can switch to openchrome. I think if we include sys/types.h in the relevent via files we'll be alright. from libdrm.h: #if defined(__linux__) typedef unsigned int drm_handle_t; #else #include <sys/types.h> typedef unsigned long drm_handle_t; /**< To mapped regions */ #endif
Treecleaned.
