Welcome! Log In Create A New Profile

Advanced

Request : XGI Graphics

Posted by Gravelrash 
Re: Request : XGI Graphics
April 17, 2016 05:37AM
Same issue as above, must nuke manually the files indicated, then run
autoreconf -vi
./configure
make

I'm currently looking at how are xserver-xorg-sis (the older driver package, not packaged anymore, we should have used this) and xserver-xorg-sisusb packaged (basically the same driver, but for USB->VGA dongles using SiS and XGI chips, this is still packaged for Debian), as I'm suspecting that the make install does not do things the debian way.


> want a tester for the files you made?

More like help in where to place the binary and what to do to make it work at all.

I'm uploading the binary I made, it lacks any man and anything (you can find that online or in the source), it must be placed in the folder I said above, and then it has to be symlinked "somewhere" the debian way, I'm still looking around on where debian expects this, or if there are other things to do.



Edited 1 time(s). Last edit at 04/17/2016 08:52AM by bobafetthotmail.
Attachments:
open | download - sis_drivers.zip (232.9 KB)
Re: Request : XGI Graphics
April 17, 2016 10:31AM
Quick update, it seems that (thankfully) there isn't any real change in debian packaging apart from the mentioned folder change, so I spliced configs and sources to make a new debian package.

For now it builds fine on my desktop and the debian package it spits out is legit and does what it is supposed to do.
Always a pleasure working with debian packaging system.

Will now alter the version numbers and do other minor cosmetic changes and then recompile it on the thinclient.
Afterwards i'm going to upload it for you to try configuring it.

If someone manages to get it running, I'm uploading the sources in my github so the package can be built by anyone.
Re: Request : XGI Graphics
April 17, 2016 11:28AM
Done, attaching armel package, install it manually as normal.

Crossing fingers. :)

EDIT: this driver is called "sis", I suppose that this name has to be used in xorg.conf instead of the "fbdrv" which is the framebuffer driver.



Edited 1 time(s). Last edit at 04/17/2016 12:34PM by bobafetthotmail.
Attachments:
open | download - xserver-xorg-video-sis_0.10.8-1_armel.deb (225.1 KB)
Re: Request : XGI Graphics
April 17, 2016 12:59PM
Although I have no monitor yet, I am very interested to compile it from the source. Well done and congrats!

-syong
Re: Request : XGI Graphics
April 17, 2016 02:08PM
@bobafetthotmail,

> Always a pleasure working with debian packaging
> system.

> Will now alter the version numbers and do other
> minor cosmetic changes and then recompile it on
> the thinclient.
> Afterwards i'm going to upload it for you to try
> configuring it.
>
> If someone manages to get it running, I'm
> uploading the sources in my github so the package
> can be built by anyone.

Well done :)

It would be cool. I can clone and build from your GitHub for basic rootfs release. The package size is small so if would be fine to include.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Request : XGI Graphics
April 17, 2016 02:35PM
> Although I have no monitor yet, I am very interested to compile it from the source. Well done and congrats!

Paranoids, paranoids everywhere. :)

Here is the github with the source https://github.com/bobafetthotmail/Unofficial-Debian-xserver-xorg-video-sis

To build it and make a package without signing it cd in the folder you downloaded and write

debuild -b -uc -us

in the command line.

If you don't have that command, install "devscripts" package.

If you are missing packages for compilation (likely) it will stop and tell you what you need to install.

EDIT: please note that I haven't tested it nor configured xorg to use it. If you find a working configuration please report back.



Edited 2 time(s). Last edit at 04/17/2016 03:14PM by bobafetthotmail.
Re: Request : XGI Graphics
April 17, 2016 05:20PM
@bobbafetthotmail

just downloaded the .deb file, will have a couple of hours monday morning to see where i can go with the xorg.conf

from early readin based on the one i uploaded, there appears to need the following changes

pci device needs changing
replace first fbdev reference with sis
Xorg -configure (will cause it to work out a config file *if it can* then move to teh correct launch directory


will know more monday



Edited 1 time(s). Last edit at 04/18/2016 08:49AM by Gravelrash.
Re: Request : XGI Graphics
April 18, 2016 08:49AM
bobafetthotmail Wrote:

> Paranoids, paranoids everywhere. :)

Let's image xscreensaver on the monitor just like good old days...

-syong
Re: Request : XGI Graphics
April 19, 2016 07:05AM
@syong - the starfield as a background would be fun :)

@bobbafetthotmail
installed you deb file (cos im brave like that :o) ) and can give the following feedback.
install without any obvious errors, i have tried to load the driver, however it seems to fail each time i do - similar to what you find. im still working through options and settings.

one thing to note - when issuing an Xorg -configure to create an x-probed config file, x doesnt recognise that we have a display it can use, not sure where the issue lays but i will keep digging and see what i can find. output from Xorg -configure is as below. i would be interested to see if yours matches mine?

root@hpt5325:/var/log# Xorg -configure

X.Org X Server 1.16.4
Release Date: 2014-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-0.bpo.4-armmp-lpae armv7l Debian
Current Operating System: Linux hpt5325 4.4.0-kirkwood-tld-1 #1 PREEMPT Mon Jan 25 20:35:24 PST 2016 armv5tel
Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=spi0.0:512K(uboot),256K(sdd_firmware),64K(uboot_env),64K(permanent_uboot_env),64K(hp_env)
Build Date: 11 February 2015  01:28:48AM
xorg-server 2:1.16.4-1 (http://www.debian.org/support) 
Current version of pixman: 0.32.6
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 19 13:58:39 2016
List of video drivers:
	cirrus
	r128
	sisusb
	mga
	siliconmotion
	mach64
	neomagic
	trident
	ati
	sis
	tdfx
	savage
	radeon
	vesa
	fbdev
	modesetting
(++) Using config file: "/root/xorg.conf.new"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
vesa: Ignoring device with a bound kernel driver
(EE) 
(EE) Backtrace:
(EE) 
(EE) Segmentation fault at address 0x0
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE) 
(EE) Server terminated with error (1). Closing log file.
Aborted

Re: Request : XGI Graphics
April 19, 2016 12:41PM
ATM I don't have time to fire up my thinclient and run tests (because one thing starts another and I end up going to bed at 4 AM, not good, I also have a job), so I'm just telling you what I planned to do myself back then when all this started.

When I looked around for people who manually configured this thing in recent times (at least wheezy) I found this page http://georgik.sinusgear.com/2011/02/01/linux-x-org-sis-driver-configuration/
where you see an example config.

He talks about the main driver creator's site (he is cited as a source of info by more or less anyone that worked with the sis driver), a site that seems to be dead for good since 2009 or so, but by the powers granted by thy mighty WABAC, I can resurrect it here https://web.archive.org/web/20081222122518/http://www.winischhofer.eu/linuxsisvga.shtml

He also talks about a "sisctrl", a gtk2 control panel/system for the sis driver that helped him configuring things.
Which of course has to be compiled from source (but the guy from 2011 did it so we can do that too with some luck), and the source package is in the site resurrected above, and now attached to this post too, just because it is tiny.

Next round for me will commence in the weekend, if you want to try out something while you wait, you should have the best info around now.
Attachments:
open | download - sisctrl-0.0.20051202.tar.gz (651.1 KB)
Re: Request : XGI Graphics
April 19, 2016 12:46PM
thanks for that - i managed to get slightly further since my last post, by removing some offending drivers like the vesa one and that stopped the segfault for now. i will have a look at your attached code and see if i can get anywhere further along.

many thanks for the work so far

EDIT: i know all about the working on things till "silly-o-clock" as i have done it so many times in the past and then toddled off to work the following day..... did i say "toddled" i meant, dragged my sorry carcas out the door when even caffeine wasnt doing its thing
:)



Edited 1 time(s). Last edit at 04/19/2016 12:53PM by Gravelrash.
Re: Request : XGI Graphics
April 23, 2016 01:39PM
Today I had less time than anticipated, I managed to compile successfully the sisctrl utility on my main PC, wanted to fix its debian packaging too, but I'm unsure how to specify one of the build dependencies that is found in different folders depending from the architecture. For now you must specify it by hand on compile time, while the debian packaging system can't yet do so to package it.

Will do some tests on my box tomorrow.


Now the build-it-yourself instructions as I don't have any armel binary to share for now.

from the sources provided above, edit the configure.ac

AM_INIT_AUTOMAKE

must become

AM_INIT_AUTOMAKE(subdir-objects)

so autoreconf stops annoying you with warnings about adding this option for future compatibility

then install libxv1 libxv1 libXxf86vm-dev libXxf86vm1 libxv-dev libxv1 libgtk2.0-dev libglib2.0-dev x11proto-composite-dev x11proto-core-dev x11proto-damage-dev x11proto-fixes-dev x11proto-fonts-dev x11proto-input-dev x11proto-kb-dev x11proto-present-dev x11proto-randr-dev x11proto-render-dev x11proto-resource-dev x11proto-scrnsaver-dev x11proto-video-dev x11proto-xext-dev x11proto-xf86bigfont-dev x11proto-xf86dga-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev x11proto-xcmisc-dev

(some may be unneeded, I selected the x11proto libraries that could realistically apply to this)

run
autoreconf -vi

then go look where in your system is placed a library called libXv.so in 64bit linux it is found in /usr/lib/x86_64-linux-gnu, on the arm rootfs it should be /usr/lib/arm-linux-gnueabi, in 32 bit debian it should be in /usr/lib/i386-linux-gnu

then run (assuming you have such lib in the arm rootfs place I said above)
./configure LIBS="-lm" --with-xv-path=/usr/lib/arm-linux-gnueabi

The first option should avoid a missing symbols error, the second forces a custom folder for finding the above library.

then compile with

make

At the end of the compilation you should have a sisctrl binary in the compile folder, and sisctrl.1x seems to be the manual file.

this is the output of sisctrl -h

./sisctrl [-display host:dpy] [-screen screen] [-force] [-status]
	[-setgammabrightness|-sg] [-listmodes|-lm] [-setmode mode] [-resize] 
	[-setcrt1 device] [-setcrt2 device] [-setlcdscaling mode]
	[-setlcdcentering mode] [-settvstandard standard]
	[-settvoverscan mode] [settvsapect mode] [-setxvcrt num]
	[-settvxpos x] [-settvypos y] [-settvxscale x] [-settvyscale y]
	[-noxvdemo] [-nosystemtray] [-noconfirm]
	[-v|-version] [-h|-help|-?]
display: target display in host:dpy format
screen: screen number (used only if Xinerama is detected)
force: to delete lock file (and ignore other eventually running sessions)
noxvdemo: disable xv demo graphics in Video settings tab
nosystemtray: disable system tray icon
iconify: start with iconified window
noconfirm: disable mode change confirmation window
-- Specifying one of the following options will disable the GUI:
version: print version and quit
setgammabrightness: set stored gamma brightness from driver and quit
status: print current display status and quit
listmodes: list all supported display modes and quit
setmode: set display mode, use -listmodes to find out about mode number
resize: resize desktop to display mode
setcrt1: set CRT1 device ("on"="vga", "off", "dvi-d"="lcd")
setcrt2: set CRT2 device ("dvi-d"="lcd", "tv", "svideo", "cvbs", "svideo+cvbs",
	"hivision", "ypbpr1080i", "ypbpr720p", "ypbpr576p", "ypbpr576i",
	"ypbpr480p", "ypbpr480i", "dvi-a"="vga", "off")
setlcdscaling: set LCD scaling mode ("default", "on", "off")
setlcdcenter: set LCD centering mode ("default", "on", "off")
settvstandard: set TV standard ("pal", "ntsc", "palm", "paln", "ntscj")
settvoverscan: set TV overscan ("bios", "overscan", "underscan", "soverscan")
settvaspect: set YPbPr TV aspect ratio ("4:3", "4:3lb", "16:9")
setxvcrt: set video overlay CRT number (1 or 2)
settvxpos: set TV x position (-32 <= x <= 32)
settvypos: set TV y position (-32 <= y <= 32)
settvxscale: set TV x scale (-16 <= x <= 16)
settvyscale: set TV y scale (-4 <= y <= 3)

this is the manual

.TH SISCTRL 1x "June 19, 2004"
.SH NAME
sisctrl \- Display Control Panel for XFree86/X.org SiS driver
.SH SYNOPSIS
.B sisctrl
.RI [ options ]
.BR
.SH DESCRIPTION
.B sisctrl
is a gtk-2.x based tool for the XFree86/X.org SiS ("sis") driver to tune
the display parameters during X server run-time. Among other features, it 
allows switching and changing output devices, tuning TV output, gamma
correction and Xv (hardware video) properties. It also supports switching
the display mode and resizing the desktop using the RandR extension.
.PP
To allow this tool to work, it is required to add
.PP
   Option "EnableSiSCtrl" "on"
.PP
to the corresponding Device section of XF86Config-4/xorg.conf.
.PP
.SH OPTIONS
.TP
.B \-h, \-help, \-?
Show summary of options.
.TP
.B "\-display \fIdisplay\fP"
This argument allows you to specify the server sisctrl should be running on;
see \fIX(7x)\fP. For example: sisctrl -display :0.0
.TP
.B "\-screen \fIscreen\fP"
This argument allows you to specify the screen sisctrl should configure. This
argument is only used in Xinerama mode. Usually, screen 0 is CRT2,
screen 1 is CRT1. This argument is ignored if the X server is not running in
Xinerama mode. For example: sisctrl -screen 0
.TP
.B "\-force"
This argument forces sisctrl to start, even if it detects another running
session. This is dangerous and should only be used if sisctrl - for
some reason - crashed or was killed with a KILL signal and at starting
(hence wrongly) complains about another running session.
.TP
.B "\-noxvdemo"
Disables display of a demo-video in the Video-tab.
.TP
.B "\-status"
Prints the current display status and exits.
.TP
.B "\-version"
Prints the program version and exits.
.TP
.B "\-setgammabrightness, \-sg"
This argument makes sisctrl set the pre-defined gamma brightness and
pre-brightness values given by the StoredGammaBrightness and
StoredGammaPreBrightness driver options and exit (without starting the GUI and
without requiring any user interaction). Since the X driver cannot set
the gamma ramp itself, you need to execute sisctrl with this argument in
order to do this at server start. Most conveniently, add "sisctrl -sg &"
at the beginning of your ~.xsession file.
.TP
.B "\-setcrt1 \fImode\fP"
This sets the CRT1 mode. \fImode\fP is either "on" =("vga"), "off" or "lcd".
"lcd" is for activating LCD-via-CRT1 and only supported on some machines.
Using this parameter sets the mode immendiately and does not start the GUI.
.TP
.B "\-setcrt2 \fImode\fP"
This sets the CRT2 mode. \fImode\fP is either "lcd", "tv", "svideo", "cvbs",
"svideo+cvbs", "scart", "hivision", "ypbpr1080i", "ypbpr720p", "ypbpr480p",
"ypbpr480i", "vga" or "off". "tv" is to be used on Chrontel systems, whereas
the specific plug type "svideo", "cvbs" etc is meant for systems with SiS
video bridges. Using this parameter sets the mode immendiately and does not
start the GUI.
.TP
.B "\-settvstandard \fIstd\fP"
This sets the TV standard. \fIstd\fP is "pal", "palm", "paln", "ntsc" or
"ntscj". Using this parameter sets the mode immendiately and does not
start the GUI.
.TP
.B "\-settvoverscan \fImode\fP"
This sets the TV overscan mode on systems with a Chrontel TV encoder. \fImode\fP
is "bios, "underscan", "overscan" or "soverscan". "soverscan" is supported in
PAL only. Using this parameter sets the mode immendiately and does not
start the GUI.
.TP
.B "\-settvaspect \fImode\fP"
This sets the YPbPr output aspect ratio on some newer systems. \fImode\fP is
"4:3", "4:3lb" or "16:9". Using this parameter sets the mode immendiately and
does not start the GUI.
.TP
.B "\-setxvcrt \fIcrtnumber\fP"
This selects whether the video overlay should be used for CRT1 or CRT2 on
machines with a SiS315, 740, 650 or 330. \fIcrtnumber\fP is either "1" or "2".
Using this parameter sets the mode immendiately and does not start the GUI.
.TP
.B "\-settvxpos \fIoffset\fP"
.TP
.B "\-settvypos \fIoffset\fP"
Select the TV screen position on your TV. \fIoffset\fP must be within the
range from -32 to 32. Using this parameter sets the mode immendiately and
does not start the GUI.
.TP
.B "\-settvxscale \fIscaleno\fP"
.TP
.B "\-settvyscale \fIscaleno\fP"
Select TV zooming (scaling) mode. \fIscaleno\fP must be within the range from
-16 to 16 for X, and -4 to 3 for Y.

.SH SEE ALSO
X (7x), XF86Config-4 (5x).
.PP
.IR http://www.winischhofer.net/linuxsisvga.shtml

.SH AUTHOR
Thomas Winischhofer <thomas@winischhofer.net>



Edited 2 time(s). Last edit at 04/24/2016 03:18PM by bobafetthotmail.
Re: Request : XGI Graphics
April 25, 2016 04:31AM
Holy hot damn batman!

I tested the thinclient a bit but the driver refuses to start, saying it did not find suitable hardware.
Sisctrl does the same.

excerpt from the xorg log file (yes, the GPU on this box is at PCI 01:00.0)

[   769.652] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
[   769.666] (II) Module evdev: vendor="X.Org Foundation"
[   769.666]    compiled for 1.16.0, module version = 2.9.0
[   769.666]    Module class: X.Org XInput Driver
[   769.666]    ABI class: X.Org XInput driver, version 21.0
[   769.666] (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620,
        SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H,
        SIS315PRO/E, SIS550, SIS650/M650/651/740, SIS330(Xabre),
        SIS660/[M]661[F|M]X/[M]670/[M]741[GX]/[M]760[GX]/[M]761[GX]/[M]770[GX],
        SIS340
[   769.667] (II) SIS: driver for XGI chipsets: Volari Z7 (XG20),
        Volari V3XT/V5/V8/Duo (XG40)
[   769.668] (++) using VT number 1

[   769.668] (--) controlling tty is VT number 1, auto-enabling KeepTty
[   769.668] (WW) Falling back to old probe method for sis
[   769.668] (WW) SIS: No matching Device section for instance (BusID PCI:0@1:0:0) found
[   769.668] (EE) No devices detected.
[   769.669] (EE)
Fatal server error:
[   769.669] (EE) no screens found(EE)
[   769.669] (EE)


I looked again at lspci output and the GPU reports itself as a Volari Z11
root@t5325:~# lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC (rev 03)
01:00.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Z11/Z11M


The damn driver does not advertise support for Volari Z11. It's too "new" for it. :/

Still, since we don't care about 3D (as the driver cannot do 3D anyway) and the 2D part of this hardware shouldn't be terribly different from older Volari chips, I was thinking about fooling the system into thinking that this is a Volari Z8 or whatever just to get this driver to run.
Is this stuff doable by changing the dtb?
If yes, can you provide a dtb disguising this card as either Volari Z7 (XG20), or Volari V3XT/V5/V8/Duo (XG40) (or more possible permutations as possible, I can't find any real info about this stuff, so I'm basically going in blind.

Otherwise I'll have to try hack the driver to "recognize" this card as an older Volari, which will also try to do if we manage to get this working with the (simpler?) dtb hack.

Also, it seems like RHEL6 has drivers for this card, but I'm not finding source anywhere for that, so it's probably a binary-only. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/xorg-x11-drv-xgi.html

This place http://www.sunixusa.com/product/vga0411l/ has binary drivers supposed to work in 3.x linux kernels (I doubt they do). Of course they are x86 binaries, so they can be useful only for reverse-engineering, but there are at least useful info about pci and vendor ID codes and chipset names in the configs, which is a BIG THING since I don't have acces to ANY info about this.
Volari Z11 seems chipset XG27, while Volari Z7 is XG20, and Volari XG Z9 (varies) is XG21.

It's more annoying than I first thought, but I still have reasonable hope that we can hack this to work.



Edited 4 time(s). Last edit at 04/25/2016 08:53AM by bobafetthotmail.
Re: Request : XGI Graphics
April 25, 2016 07:02AM
@bobbafetthotmail - your findings match mine from the other driver i found.

its almost as if the support for the chipset was removed in future releases. what im going to do next weekend is to load a system up with wheezy and see if the driver from there triggers the card, this should at least tell us if we need to poke around with the dtb file some more.

when i say wheezy - i mean the vanilla wheezy from debian and not the one provided by "Mr Bodhi"



Edited 1 time(s). Last edit at 04/25/2016 07:03AM by Gravelrash.
Re: Request : XGI Graphics
April 25, 2016 09:15AM
I'm suspecting that dtb cannot really change pci ids, so I'm analyzing the driver source anyway

....

Good, the pci and vendor ids for Volari Z7 of the binary driver for that card above match with those in the current source, good chances the others aren't bogus.

I'll try adding the Volari Z11 IDs in the driver and adjusting all places where it checks for such IDs to look for the new ones too, hoping that the 2D system is just a respin of the same hardware and can be operated by the same driver.
These are the ids, for those interested:
vendor   pci id
0x18ca   0x0027	"Card:XGI Volari Z11"	"eXtreme Graphics Innovation"


>its almost as if the support for the chipset was removed in future releases.

I doubt this card has EVER been in the sources of these drivers.

I strongly suspect that HP devs added the pci ID in their driver that is based on the Marvell_Z11_XGIfb.tar.gz mentioned by others that is floating around in HP ftp servers with other open sourcecode.
As I cannot find any pci ID matching the Volari Z11's in that code, and it is even based off an old version of the same driver we have already.

All sources for drivers for these chips have Thomas Winischhofer name in their sources (the guy from that site above), but all have diffent ages, the one from xorg is of course the newer (no duh), some other drivers differ as they have more code for 3D support wich is completely worthless now and has been mostly removed.

Also, our good friend Thomas stopped working at the driver in 2007 (according to what he said in his site), more or less the times when the Volari Z11 came out, it's not likely he got a Z11 at day one to test the driver on, and others didn't add much, they did mostly mantaining, if changelog means anything.
http://volarigamers.com/xgi-launches-volari-z11

>what im going to do next weekend is to load a system up with wheezy and see if the driver from there triggers the card

I think it's pointless, the driver checks for pci IDs and if the chip answers with an unknown ID it will not load, period.

You can try looking around in sources that have the pci ID I wrote above, (use any search tool that can search inside text files).

EDIT: the only drivers that have this ID are the ones I tried to compile above, the xgi ones, that didn't compile.



Edited 2 time(s). Last edit at 04/25/2016 09:24AM by bobafetthotmail.
Re: Request : XGI Graphics
April 26, 2016 03:38PM
Ok, quick update, mixed news.

Connor Behan (the last developer of the xgi driver) answered to my mail, and with his help now the dumb thing compiles and loads (there were other issues I fixed, but anyway).

I've made another debian source package on github (i'm going to become a debian mantainer someday :) ) https://github.com/bobafetthotmail/Unofficial-Debian-xserver-xorg-video-xgi
And attaching a .deb for those that want to try it.

Good news is that this is the driver we are looking for.

[  5373.992] (II) XGI: driver for XGI chipsets: Volari V8_V5_V3XT, Volari Z7_Z9_Z9s,
        Volari Z9_Z9s, Volari Z11

Bad news is that this driver does not recognize the Volari in this box.

[  5373.992] (++) using VT number 1

[  5373.992] (--) controlling tty is VT number 1, auto-enabling KeepTty
[  5373.993] (EE) No devices detected.


I also tried to hack the sis driver by adding the pci IDs of the Volari Z11, but it still does not seem to recognize it, same log output.

So at this point I'm suspecting that there is something amiss in the hardware configuration or kernel here.

I ask to whoever knows more at a lower level, who gives these pci IDs to the driver?

It seems to use "libpciaccess" library to get these IDs from wherever, has anyone some experience with that?

I'm probably going to have a look at the kernel hack by HP to see what they did to get it working, but I doubt I will understand much, and I don't have much hopes to get anything useful (standards-compliant) from it.

EDIT: ah yes, uploading also pre-compiled package.



Edited 1 time(s). Last edit at 04/26/2016 04:02PM by bobafetthotmail.
Attachments:
open | download - xserver-xorg-video-xgi_1.6.1-1_armel.deb (112.9 KB)
Re: Request : XGI Graphics
April 26, 2016 09:01PM
I did not see anything about video hardware in the dts file.

Bodhi, should there be a 'compatible' for the video card there?

-syong
Re: Request : XGI Graphics
April 27, 2016 12:08AM
syong Wrote:
-------------------------------------------------------
> I did not see anything about video hardware in the
> dts file.
>
> Bodhi, should there be a 'compatible' for the
> video card there?

Yes, I think so. That's if the driver can parse it. I've not looked into this so not sure that boba deb package does, either :) I would need to look in the source code to see if it does support Device Tree.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 1 time(s). Last edit at 04/27/2016 12:09AM by bodhi.
Re: Request : XGI Graphics
April 27, 2016 01:30AM
I posted nonsense. please ignore.



Edited 4 time(s). Last edit at 04/27/2016 02:08AM by bobafetthotmail.
Re: Request : XGI Graphics
April 27, 2016 02:09AM
bobafetthotmail,

If the driver supports device tree then it would parse or receive (from a higher level driver) the tree nodes and you'll find something like "property", "compatible", "of_property" ... clauses in the driver.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 2 time(s). Last edit at 04/27/2016 02:13AM by bodhi.
Re: Request : XGI Graphics
April 27, 2016 03:04AM
hmm, what I said was actually true.

I'm pretty sure that this driver does not deal directly with hardware, it heavily relies on a xorg library called libpciaccess to do that by calling its functions and structs.

It seems all decent xorg drivers have been migrated to this library to standardize and abstract away most low-level things. Should be a good thing as it's more likely that someone will need it to support device trees too.

the source for such library. https://cgit.freedesktop.org/xorg/lib/libpciaccess/

searching through the sources of such library i'm not seeing anything talking of source trees specifically (it does once but it talks of its own internal device tree with the results)

Form Red hat docs,
"On Linux, libpciaccess uses either the sysfs virtual file system or the /dev/mem device to communicate with PCI devices. "
https://www.centos.org/docs/5/html/5.4/technical-notes/libpciaccess.html

I assume that this means device tres are supported, right? That's stuff generated by the kernel.

Also they do provide (the source for) a tool to test out the library, can you make a (some) test dtb(s)?



Edited 2 time(s). Last edit at 04/27/2016 03:08AM by bobafetthotmail.
Re: Request : XGI Graphics
April 27, 2016 03:21AM
> "On Linux, libpciaccess uses either the sysfs
> virtual file system or the /dev/mem
device to
> communicate with PCI devices. "
> https://www.centos.org/docs/5/html/5.4/technical-n
> otes/libpciaccess.html
>
> I assume that this means device tres are
> supported, right? That's stuff generated by the
> kernel.

That's not necessarily true. I've came across old drivers that have sysfs. If the device tree is support then the kernel would generate /dev/proc/device-tree.

>
> Also they do provide (the source for) a tool to
> test out the library, can you make a (some) test
> dtb(s)?

I guess I should take a peek of the source to see what's in there.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Request : XGI Graphics
April 27, 2016 03:31AM
> I guess I should take a peek of the source to see what's in there.

Yeah, sorry about that. That's as far as I can go, I don't know enough to understand what happens in there.
Re: Request : XGI Graphics
April 27, 2016 04:06AM
Re: Request : XGI Graphics
April 27, 2016 04:56AM
No, but I think this driver isn't done terribly well overall and I think we are the first people actually trying to use this source in the last 6 years or so.

I had to fix a dumb error that was causing this issue

[ 4231.319] (EE) LoadModule: Module xgi does not have a xgiModuleData data object.

and of course this causes a failure to load the driver when starting xorg.

It was fixed by adding a simple "_X_EXPORT" at the beginning of line 247 in xgi_driver.c after I google-searched the code block that was responsible of Module Data and played "spot the differences" with the source and that.

I didn't check but I'm suspecting that this bug goes all the way back to 2010 or even earlier, so this driver hasn't been operational for a loong time even if it compiled fine on x86 (but not on ARM).

Editing linux files from windows is nothing by comparison, and it is easy to fix with dos2unix tool (as suggested by a guy answering that patch). Also because that patch is in the changelog so it went through.

Worst coming to worst, can the driver be just hacked to work with this box only by just hacking the chip detection logic to default to XGI Volari Z11 and hard-code other relevant things? (I can probably do the hacking if you tell me fi there are any other magic numbers that must be hard-coded)

That way we can simply have a xorg-video-xgi-t5325 that works only for this box and close the case, it's unlikely others will need to use this driver in the future with dtbs, if at all.



Edited 2 time(s). Last edit at 04/27/2016 04:59AM by bobafetthotmail.
Re: Request : XGI Graphics
April 27, 2016 09:25AM
@all "i am not worthy!" : Theres some fantastic work being done here

and apologies to everyone too for finding a marvel device with a graphics card attached..



Edited 1 time(s). Last edit at 04/27/2016 01:49PM by Gravelrash.
Re: Request : XGI Graphics
April 27, 2016 01:58PM
@all

im way beyond my skill level here when it comes to understanding and porting code, but as bobbafetthotmail mentions that the "new drivers" utilise support for libpciaccess and this is a package we can install from debian repositories. does the following link help anyone?

http://www.x.org/wiki/PciReworkHowto/ : "Here's a list of steps you need to take to convert a video driver to the new libpciaccess library"

it mentions about adding a few additional lines to allow drivers to utilise libpciaccess library.
Re: Request : XGI Graphics
April 27, 2016 03:22PM
> and apologies to everyone too for finding a marvel device with a graphics card attached..

Well, this is a hacking/tinkering forum, so it's not that bad.

Personally, I'm having some fun learning C and getting myself a bit into the linux development.

I wasn't expecting it to be so annoying but it still seems doable.

Of course I can't speak for bodhi, we pulled him into this puzzle while he also has the switch driver for that other kirkwood-based router, and probably other things to do too. :)


> im way beyond my skill level here when it comes to understanding and porting code

Consider learning some. Knowing how to code is important these days, and will complement your hardware hacking skills. Even Obama said that coding was important. :)

Anyway, the current issue is about the fact that this driver (like most decent ones) is designed to be generic and work on slightly different GPUs so it looks somewhere to get IDs and other static data about the hardware to use when in operation.

Since our GPU does not have its own BIOS nor there is a BIOS anywhere to look into, this driver cannot read these info, or so it seems.

Bodhi said the driver cannot work with dtb in its current form (another place this driver could look for getting these data)

I said that if adding support for dtb in this driver is too complex (don't know, only bodhi can answer this) it is likely a good idea just specialize this driver by placing all IDs and static data inside it.
That way the new driver will work ONLY for this GPU (and maybe ONLY) on this device, but will save time.
This is the usual way 99% of embedded device drivers follow.
Re: Request : XGI Graphics
April 27, 2016 05:11PM
>
> Of course I can't speak for bodhi, we pulled him
> into this puzzle while he also has the switch
> driver for that other kirkwood-based router, and
> probably other things to do too. :)
>

That and other imprtant things to do such as a day job :)

> I said that if adding support for dtb in this
> driver is too complex (don't know, only bodhi can
> answer this)

It is a lot of works. Speaking only for myself, I would not want to attempt it because it'll take way too much time to do.

> it is likely a good idea just
> specialize this driver by placing all IDs and
> static data inside it.
> That way the new driver will work ONLY for this
> GPU (and maybe ONLY) on this device, but will save
> time.
> This is the usual way 99% of embedded device
> drivers follow.

Agree.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Request : XGI Graphics
April 27, 2016 06:38PM
@all

speaking as a "user" : if we can get to the point where this device can have the accelerated graphics for this and only this device then great.

Speaking as a tech : This is a lot of work for whoever is willing to take this forward and i volunteer to test and assist as much as i can which admittedly is limited help at this juncture.

Speaking as a hacker/tinkerer : We are at the point where we have rudimentary graphics and working sound output. this in itself is a massive acheivement by those involved and i applaud it!!!!

its over to you bobbafetthotmail, you are the "lead" now for the graphics output, are you willing to go further?
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: