Re: [XFree86] Multiple graphics cards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Bolton wrote: | Hi all, | | This has been bothering me all night. I've got 2 graphics cards and 3 | monitors and I'm struggling to get the second graphics card up and | running. The primary graphics card is an AGP NVIDIA 5900XT and the | secondary is a PCI SIS 315PRO. | | From the log file I've included below you can see it gives the error.. | (WW) SIS: No matching Device section for instance (BusID PCI:0:13:0) found | Yet in my xorg.conf log I've stated busid PCI:0:13:0 under the section | decive for that card. | | I've been googling all night and tried various different combinations of | settings in the xorg.conf file but I just can't get my head round it. | Someone please put me out of my missery. 1. You're running X.org, not XFree86. 2. Regardless, remove the Screen 2 statement from the Videocard2 device section. Screen is only mandatory on cards that control more than one output, and then it should start with 0. Thomas - -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOr4szydIRAktyUcRAklzAJ438YRbi1Au16F3IktR+0tQUHHY7wCeMo5f njhE6nhrKJsRkkCLrRUFAps= =5W2g -END PGP SIGNATURE- ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Dual monitor, Xfree no go, laptop, Debian woody, dual boot with XP
Your X server is too old. It was released before the SiS 650/740 was. Options: 1) Download an updated driver from my website and explicitely state Driver sis in your XF86Config-4 (because the ati driver during probe thinks it identified some ATI chip). 2) Run Debian sarge (testing) or unstable. Thomas Dave Sampson wrote: Alright yall... dual monitor info is far and few between... info Laptop: Viper M270S by eurocom eurocom.com Chipsets: SIS Video: 1 x 14 '' LCD 1 x AGP 2nd Screen: 17'' Compaq V75 Mouse: Logitech mx700 User Input: on board touch pad and 2 buttons ram 750MB OS: winXP / Debian (woody with 2.6 kernel) Boot manager: Boot Magic as primary, LILO for Linux Options Distro method: Base CD and then net install Pertinent included pckgs: xfree86, x windows, tcl/tk, desktop History: I have run Cygwin in the past ok I have also run RH9 successfully due to project requirements I'm switching to Debian Problem: Easy enough, the x server wont go... I have include the log, pci scan and config files I figure I need to find out what Device ID to put into the Device section Tried the following and none worked 0:0:0, 0:1:0, 0:2:0, 0:2:2, 0:2:3, 0:2:5, 0:2:6, 0:2:7, 0:10:0, 0:11:0, 0:12:0, 1:0:0 now I know that 2:0:0 is a WLAN card in the PCMCIA slot 0:10:0 is ethernet 0:2:7 is audio 0:0:0 is just listed as SIS 650 0:1:0 is listed as sis SG86c201 when I use ID 1:0:0 I do not receive a Device error so I am not conviced this is the problem, but can't interpret the output of the log to pin point it I've managed to get RH9 running two headed in the past but I have exhausted the regular roots... perhaps the DEBOOTSTRAP setup did not configure properly Any ideas? Goal: 1. Get my LCd to run a x-server 2. run dual head probably using Xinerama (or what ever its called) Cheers P.S respond to e-mail directly please -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/12/15 07:03:28 Log message: Another fix for MiscPassMessage(): Make status reliable. Modified files: xc/programs/Xserver/Xext/: xf86misc.c Revision ChangesPath 3.46 +3 -2 xc/programs/Xserver/Xext/xf86misc.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/12/14 16:47:19 Log message: Make MISC extension's PassMessage() actually work and fix memory leaks. How did this obviously untested stuff get into CVS??? Modified files: xc/programs/Xserver/Xext/: xf86misc.c Revision ChangesPath 3.44 +16 -5 xc/programs/Xserver/Xext/xf86misc.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/12/14 16:48:43 Log message: Fix MISC extension's PassMessage (MsgVal was trashed; memory leaks) Bump MISC extension minor version number to 9 to indicate that PassMessage is actually usable. Modified files: xc/include/extensions/: xf86mscstr.h Revision ChangesPath 3.14 +2 -2 xc/include/extensions/xf86mscstr.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [XFree86] no screens found
Melissa Golter wrote: To Whom It May Concern ;] While installing RH7.3 (yes, I know, it is old, but i need to run an application; each newer linux version has its own bug when running it, so, RH7.3 is still OK) I made the mistake of not testing when I changed 16 bit color to true color -- I forgot I had not installed the NVIDIA card, but still had the unrecognized and problematic ~SIS300 card installed. Also, the monitor i am using (SGI -- Sony -- GDM17E21 was not on the RH7.3 list so I went with the default the install-GUI chose (SGIX1000), but input the HSync and VSync values for the GDM12E21... Other than problems with the above defaults, I don't know why, when switching into graphics mode from text mode, the error no screens found popped up. (PS I am noting this for no good reason except that it might reflect same problem: I (also) couldn't see the Grub Loader on startup. I dunno if that is a prob with Grub, or with the no screens issue, tho...cuz another OS shoulda loaded...but it didn't...as I said, am noting this as the Grub loader is somewhat graphical :P ) If anyone can help, I have attached the XFree86.log (for those who dislike attachments, there is a copy of it at ftp.evl.uic.edu/pub/INcoming/ABOUT), but below is a snippet of the log (XFree version 4.2.0): Total Memory: 1023 64Kb banks (63M) (EE) VESA(0): No matching modes (II) UnloadModule: vesa (II) UnloadModule: ddc (II) Unloading /usr/X11R6/lib/modules/libddc.a (II) UnloadModule: int10 (II) Unloading /usr/X11R6/lib/modules/linux/libint10.a (II) UnloadModule: vbe (II) Unloading /usr/X11R6/lib/modules/libvbe.a (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found If it is a question of changing the XF86Config file, yea [I looked at the XF86Config file but don't see where I should/can change the screen values; the XFree86.org documenation on version 2.4.0 mentions newer sis card changes, but...] any help would be appreciated Either set DefaultFbBpp 32 in the screen section (below the DefaultDepth 24 statement), or use the sis driver, for which the current version is available on my website (yes, even for 4.2.0). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Handling multi-monitor configuration
David Dawes wrote: I've been reworking the multi-monitor configuration support that I started a while ago, and I have a patch relative to the latest XFree86 snapshot (4.4.99.17) that implements it. This provides a better way of handling the multi-monitor configuration than the current mergedfb methods. It does so by allowing multiple Monitor entries in the Screen sections, and allowing per-Monitor Display subsections for providing per-monitor parameters. The patch implements the configuration changes and some helper functions that drivers can use to access the new data. The implementation is backward-compatible in the sense that existing drivers will continue to function without knowledge of these changes. An example of how the configuration looks is as follows: Section Screen Identifier Multi-Monitor Demo Screen Device Multi-Monitor Device 1 Monitor 1 My Monitor Monitor 2 My Monitor Monitor 3 My Other Monitor DefaultDepth 24 Option Screen Option Value SubSection Display Monitor 1 Modes 1024x768 800x600 Virtual 1024 768 Option MonitorOption val1 EndSubSection SubSection Display Monitor 2 Modes 1280x1024 Option MonitorOption val2 EndSubSection SubSection Display Monitor 3 Modes 1600x1200 Option MonitorOption val3 EndSubSection SubSection Display # Screen-wide display parameters EndSubSection EndSection Although my broader goal is to eliminate the need for complete static configuration, this patch also serves to provide associations between the relevant data internally in a more consistent way than is used for the current multi-monitor solutions. The patch is available at: http://www.x-oz.com/multimonconfig-1.0.diff.gz Comments and feedback are welcome. David, if this is supposed to be(come) a better way to set up mergedfb-like configurations (as I read from your introduction), it leaves some open questions: Did you consider the current MetaModes definition deprecated by this implementation? If so: - How are clone-modes to be configured? Cloning does not mean a plain mirror-mode (where both monitors show the same image); the monitors can have different resultions even in cloned modes, where the display on one of the monitors will pan inside the limits of the resolution shown on the other; one can think of this as a zoom-mode. - How are the modes to be cycled through? IE: If I press Ctrl-Alt-+, what happens? Supposedly all monitors switch to the next mode in the list? This makes combining modes on purpose (nearly) impossible. Suppose that one of the modes listed in the Display subsection is eliminated during validation (due to refresh/clock/etc reasons, whatever), all following modes will be combined with a different (other Monitor's) mode than (eventually) intended. And furthermore: If you make Virtual a valid part of the Display-subsection, this corrupts the idea behind mergedfb in the merged-part: One of the (IMHO) advantages of mergedfb over Xinerama is that the displays are always joint, ie there is never an invisible part of the display between the monitors. If the Monitors now eventually have different Virtual-sizes, panning is unavoidable. What is the last Display-subsection for? It's commented screen-wide display parameters. Doesn't that lead to confusion if it's called Display-subsection like the others, although (as I conclude from the comment) it overrules the Display-subsections above it? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Maximizing DVI Flatpanel resolution in nVidia nv
Antonino A. Daplas wrote: Hi all, Looking at the xfree86 source of nv, it seems that the maximum resolution achieved when the input type is DDI is set by the BIOS (fpWidth/fpHeight). Is there a way to bypass this limitation such as a flatpanel display capable of 1600x1200, but only 1024x768 is achievable. IOW, what registers need to be programmed to set the panel size to a higher value. Hardware: GeForce4 Ti 4600 Display: Manufacturer: IVM Model: 4800: Name iiyama Any help will be greatly appreciated. Apart from the fact this the nv implementation is bad as it relys on the BIOS for the panel size, this particular panel's DDC data is broken. It advertizes 1024x768 as the preferred mode while being capable of 1600x1200. I very much assume the BIOS simply evaluates the DDC data in order to find out about the panel size. [Side note: This is the way many other BIOSes do it as well. This method fails miserably for plasma panels that can scale down as well.] If you (or the user that owns this panel) is capable of compiling X from source, you could try out patching nv_setup.c to hard-code pNv-fpWidth/pNv-fpHeight to 1600x1200 and see what happens. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] dri kernel modules
[EMAIL PROTECTED] wrote: Dear Sirs: I am using the Fedora core 1 distribution with a sis6326 graphics card. I am relatively new to the Linux OS and have a question to ask. In order to use the Flightgear simulator with opengl in 3d mode, I need to use the proper 3d module. I am currently using the xfree86 version 4.3.0 (fedora core1: 4.3.0-42). If I download and modprobe the file linux-drm-4.3.0-kernelsource.tar.gz, is that all that is needed to run Flightgear in 3d mode? The xfree86.log file had this line: (EE) SIS(0): DRIScreenInit failed. Disabling DRI. There is no DRI support for the 6326. Thomas ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Monitor/Driver Problem
[EMAIL PROTECTED] wrote: Ive seen Windows pretty recently so I strongly believe there isnt such a way (actually the main reason for starting this thread). While new to this forum, I have to assume that beside the expected hard-core Linux aficionados who wouldnt touch Windows with a ten-foot pole, one might encounter many disaffected Windows users and, with any luck, even recent, disgusted Windows defectors for whom the notion of not being able to fix the refresh rate of the Windows video driver was too much to bear and the last straw. Any comments pro/con are warmly invited and details dismissing my above claim will be happily appreciated and followed. And here he fires up vmware... In 2000, you need to open the display properties, select the right-most tab (Settings), click on advanced, select monitor and select a different monitor than generic or pnp, such as legacy or standard. (I only have a swedish version of Windows 2000 running under vmware here, so the actual wording of the buttons/tabs may not be exact.) In the area below, you can choose a fixed vertical refresh rate. By a really strange coincidence, ever since I converted to 4.4 Ive been fascinated by what I perceived to be the impossibility of fixing the video driver parameters in _Linux_. (that was before I discovered the subject problem with Windows). Thomas, I sent you an E-mail to this effect at the time, probably lost in the cyber fog. I never expected to be so fortunate to meet you here in this forum, so Im now taking the liberty of reproducing in full, unedited, the letter (and the questions included therein, at the end) below, so you can comment. The E-mail is dated Aug 25, 2004. My appologies, but please understand that I am a developer, no call center. My impression was that you had either config problems or theoretical questions, both not specifically related to my driver. In such cases I take the liberty of not responding to each and every mail I get. That is exactly what the mailing lists are for. Subject: XF86Config Mode Questions Dear Dr. Winischhofer, First and foremost, many thanks for your excellent Linux SiS drivers. I have an ASUS machine (P4S533-MX) with SiS651 as North Bridge. I worked with your 4.2 driver (on 2.6.7) and now I'm happily stable on 4.4 and 2.6.8.1. Also, your Linux/SiS/vga page is absolutely impressive! Good to know there are still professionals around! Everything is AOK; however, I'm a little confused about how XFree86 and your SiS driver handle the modes feature. I'd very much appreciate if you can clear me up on a few questions below (at your leisure, of course - as I said, everything is just fine, SiS driver-wise). -- In my '/etc/X11/XF86Config' file there are only two modes lines, one a comment: # Default 1024x768: 94.5 MHz (Dot Clock), 68.7 kHz (Horiz.), 85 Hz (refresh) and the other one the main line: ModeLine 1024x768 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync Then, in the Section Screen, this I got this Subsection: Subsection Display Depth 24 Modes 1024x768 ViewPort 0 0 EndSubsection The '/var/log/XFree86.0.log' file has these related lines (excerpt): XFree86 Version 4.4.0 Release Date: 29 February 2004 X Protocol Version 11, Revision 0, Release 6.6 ... Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. ... (II) SIS(0): SiS driver (2004/08/20-1) (II) SIS(0): Copyright (C) 2001-2004 Thomas Winischhofer and others (II) SIS(0): Compiled for XFree86 version 4.4.0.0 ... (II) SIS(0): Not using default mode 1024x768 (vrefresh out of range) (II) SIS(0): Not using default mode 1024x768 (hsync out of range) ... (--) SIS(0): Virtual size is 1024x768 (pitch 1024) (**) SIS(0): *Mode 1024x768: 94.5 MHz, 68.7 kHz, 85.0 Hz (II) SIS(0): Modeline 1024x768 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) SIS(0): Default mode 1024x768: 94.5 MHz, 68.7 kHz, 85.0 Hz (II) SIS(0): Modeline 1024x768 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (**) SIS(0): Default mode 1024x768: 78.7 MHz, 60.0 kHz, 75.0 Hz (II) SIS(0): Modeline 1024x768 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (**) SIS(0): Default mode 1024x768: 75.2 MHz, 56.6 kHz, 70.2 Hz (II) SIS(0): Modeline 1024x768 75.17 1024 1048 1184 1328 768 771 777 806 - hsync -vsync ... (**) SIS(0): Default mode 320x200: 12.5 MHz, 31.3 kHz, 70.9 Hz (D) (II) SIS(0): Modeline 320x200 12.53 320 328 376 400 200 206 207 221 doublescan -hsync +vsync (--) SIS(0): Display dimensions: (370, 280) mm ... (II) SIS(0): Restoring by setting old mode 0x03 -- Questions: 1. My monitor (Hitachi CM715) display is perfect at 1024x768 @ 85 Hz, i.e. as suggested by my (only) Modeline. 'XF86Config' does not contain the other Default mode lines, contrary to what
Re: [XFree86] Monitor/Driver Problem
[EMAIL PROTECTED] wrote: Hi, A - GENERAL ASUS board: P4S533-MX, 3.06GHz, 1GB Video: integrated, SiS 651 chipset. Monitor: Hitachi, CM715, 19in; 1600,1200; 30-95; 50-120 Run at, 1200x768 x 85Hz - perfect (and preferred) screen 1200x768 x 75Hz - smaller (shrunk) screen OS's: Linux 2.6.8.1 with XFree86 v.4.4, Win2K to SP4, WinXP to SP2 B - PROBLEM In Windows - on any SiS651 drivers, the ASUS original (2.13), SiS's 2.22 or their latest 3.62 - the monitor boots up on 75Hz (max). However, if monitor is left powered off UNTIL the system is fully up, the monitor/driver then powers on at 85Hz (with allowed refresh rates as high as 100 and 120! ). On Linux, with XFree86 4.4 SiS driver, the monitor is always perfect, (1200x768 x 84Hz x 68.5K - as read off the screen setup). For the record, in XF86Config, the ModeLine is 1024x768 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync C - QUESTION (and pleadings for HELP) A possible coincidence, I started noticing the Windows problem only at one point after I installed the XFree86 4.4 (and its SiS driver). I have NOT established any direct link (cause/effect) between Linux driver and Windows behavior of the monitor/driver, BUT being at my wits end, I'm wondering 1. If it's possible that the Linux SiS driver has somehow programmed the monitor to respond with a changed ID string and/or different timings, etc. which could confuse the Windows driver startup-query. 2. If the above MAY have happened (under ANY circumstances, Linux or not), whether there exists a way (utility, etc.) to reset the monitor to its original values. The SiS driver does not program the monitor. It only reads its DDC info. There is no way the monitor reports different data after this (at least not that I know of). The only issue could be that the Windows driver reads DDC1 data which is not available after booting Linux since the DDC specification says that as soon as a device is being switched to DDC2 (which the SiS Linux/XF86 driver does), it has to remain in this state until it is switched off. But I can hardly imagine that the SiS Windows driver depends on DDC1. (But then again, this is SiS... you never know... Anyway, if switching off and on the monitor doesn't help, I suggest you switch off the monitor detection in Windows and use a fixed rate there). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] X11 server crash
Manfred Sandra Heins wrote: (II) SIS(0): VESA VBE DDC transfer in appr. 0 sec. (II) SIS(0): VESA VBE DDC read failed Fact 1: Your monitor does not DDC (WW) SIS(0): Monitor0: Using default hsync range of 28.00-33.00kHz (WW) SIS(0): Monitor0: using default vrefresh range of 43.00-72.00Hz Fact 2: Your Monitor section does not provide any HorizSync or VertRefresh. Conclusion: With the default ranges, nothing about 640x480 will work. Solution 1: Add proper HorizSync and VertRefresh to your monitor section Solution 2: Add 640x480 to your Modes in the Screen section. AbiWord2-2.0.9 An open-source, cross-platform WYSIWYG word processor Add please don't send useless package lists to this mailing list. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/07/07 14:20:41 Log message: SiS driver, vacation time edition: - Overrule bogus HSync/VRefresh ranges for LCD and TV - Fix for videobridgeless systems Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis.h sis_dac.c sis_driver.c sis_opt.c sis_vb.c Revision ChangesPath 1.117 +4 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.64 +40 -44xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.192 +32 -20xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.59 +24 -6 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.48 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: cvs compile failed
Alan Hourihane wrote: Isn't Alan to update the DRI stuff to current anytime soon? We're lagging a little behind the DRI CVS, but if there's build problems Thomas, please go ahead and don't wait for me and pull what you need in. Well, for now I commented out my call to the yet-to-be-imported DRICreatePCIBusID() function. This broke the static build (modular not affected as I check the loader symbol first). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs compile failed
David Dawes wrote: On Mon, Jun 28, 2004 at 05:44:14PM +0100, Dr Andrew C Aitchison wrote: On Mon, 28 Jun 2004, Andrew C Aitchison wrote: CVS compile works for me since this change revision 3.479 date: 2004/06/23 16:58:39; author: dawes; state: Exp; lines: +2 -2 Turn XItsyServer off by default (it doesn't build). in xc/config/cf/xfree86.cf You probably need to do a make World (or at least make Makefiles) in the top level to get this change to take effect. ... However make install fails with install -c -m 0444 SecurityPolicy /usr/X11R6/lib/X11/xserver/SecurityPolicy install: cannot stat `SecurityPolicy': No such file or directory make[5]: *** [install] Error 1 make[5]: Leaving directory `/home/XFree86/4.4/std/xc/programs/Xserver/Xext/tiny' Work-around appears to be make -k install Speaking of build failures with the current CVS, some recent changes to the sis driver result in a build failure for the static server: ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(sis_drv.o): In function `SISDRIScreenInit': sis_drv.o(.text+0x4ecae): undefined reference to `DRICreatePCIBusID' Yeah, I know. Fix in the queue. Isn't Alan to update the DRI stuff to current anytime soon? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Server crash (log included)
Ronald F. Guilmette wrote: Back on the 12th of June, i.e about 13 days ago, I tried to drop a different video card into my main workstation/server system here, which is running FreeBSD 5.2.1. Unfortunately XFree86 barfed on the card. I have no idea why, and would appreciate any insight into this unfortunate problem that anyone could provide. Seems like a crash while initializing the DRM. Remove the Load dri statements or update to a new driver (available on my website). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Screen rotation for i830 driver - need help for RandR
Helmar Spangenberg wrote: Hello, is there anybody who can give me some hints a) how to tell the RandR subsystem about the rotate functionality of the i830 driver and b) how to obtain information from RandR about user requests for rotations. I really tried hard - but I failed to get behind those secrets ;-( There is no secret. RandR does not support rotation at the moment. Period. The driver needs to disable RandR if it is doing rotation on its own. See sis or nv driver on how to do this. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/20 17:43:24 Log message: SiS driver: Fix some modes on 1400x1050 and 1600x1200 panels Fix Xv (minimum overlay width; linebuffer size) Add video blitter as second Xv adaptor (M650/651 and later) Add hotplug support (including LCD) Fixes for 661/741/760 Add support for many modes for LCD Add preliminary support for SiS340 Fix LCD on ECS A90x Work-around for broken BIOSes for A907 (LCD size) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 300vtbl.h 310vtbl.h init.c init.h init301.c init301.h initdef.h oem300.h oem310.h osdef.h sis.h sis.man sis300_accel.c sis300_accel.h sis310_accel.c sis310_accel.h sis6326_video.c sis_accel.c sis_accel.h sis_common.h sis_cursor.c sis_cursor.h sis_dac.c sis_dac.h sis_dga.c sis_dri.c sis_dri.h sis_driver.c sis_driver.h sis_opt.c sis_regs.h sis_setup.c sis_shadow.c sis_shadow.h sis_vb.c sis_vb.h sis_vga.c sis_video.c vgatypes.h vstruct.h Revision ChangesPath 1.26 +88 -87xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h 1.27 +176 -111 xc/programs/Xserver/hw/xfree86/drivers/sis/310vtbl.h 1.55 +198 -220 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.50 +48 -23xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.77 +905 -1117 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.46 +51 -56xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.35 +20 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.17 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/oem300.h 1.27 +21 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/oem310.h 1.11 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/osdef.h 1.114 +88 -25xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.16 +23 -10xc/programs/Xserver/hw/xfree86/drivers/sis/sis.man 1.31 +61 -58xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.c 1.22 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.h 1.43 +34 -27xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.20 +111 -33 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.21 +29 -29xc/programs/Xserver/hw/xfree86/drivers/sis/sis6326_video.c 1.39 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.c 1.13 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.h 1.4 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_common.h 1.30 +7 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.18 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.h 1.62 +47 -16xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.21 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.h 1.15 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dga.c 1.42 +88 -71xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.c 1.13 +10 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.h 1.189 +705 -258 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.39 +9 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.58 +42 -16xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.30 +30 -22xc/programs/Xserver/hw/xfree86/drivers/sis/sis_regs.h 1.32 +136 -55 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c 1.11 +144 -158 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_shadow.c 1.9 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_shadow.h 1.46 +603 -109 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.18 +9 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.h 1.47 +27 -347 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.52 +1229 -547 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c 1.24 +31 -68xc/programs/Xserver/hw/xfree86/drivers/sis/vgatypes.h 1.36 +3 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/20 17:47:15 Log message: Update Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3282+10 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/06/20 17:54:18 Log message: Update changelog entry Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.3283+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: Register access on MIPS system
Marc Aurele La France wrote: I have looked into this more closely now and it seems there are two problems: 1) port i/o on MIPS (as on ARM32) is done with memory mapped i/o. The inb/outb macros in compiler.h look smart as they correctly add IOPortBase to the port number, but IOPortBase is not initialized throughout the entire XFree86 code as of 4.4. 2) IOPortBase is declared in compiler.h itself and hence isn't global. Therefore, any module including compiler.h will have to initialize it before using inX/outX. Since the vgahw module doesn't do this, it can't be used. The ioBase stuff (for PowerPC) is but a stopgap that can only handle single-domain systems. It should be replaced. Domain support associates a base address for the three address spaces (I/O memory PCI config) each domain is comprised of. Well. I think I give up for the time being. I'm sorry to hear that. Well, I have no choice. I have no hardware myself for testing and that crappy SiS stuff doesn't support MMIO based i/o for VGA register access... Furthermore I was educated in a mail from Jun Sun who wrote some porting-HOWTO for MIPS: My question: How do I find out about mips_io_port_base from userland (ie XFree86)? You can't. However, you can do IO from userland through /dev/port. I don't know if /dev/port is mmap'able at this point. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Register access on MIPS system
Marc Aurele La France wrote: On Tue, 8 Jun 2004, Thomas Winischhofer wrote: I am having a hard time making the SiS driver run on a MIPS machine. It's some Thoshiba system, with a little-endian CPU. (Under Debian, this goes by the name Mipsel as opposed by the big-endian Mips). The user is running Debian's extremely patched almost-4.4. Current situation: Whenever an i/o register is accessed via inb/outb macros, the X server exits with a signal 11. I checked compiler.h and figured that i/o access (as done via ports on x86), it like MMIO access on MIPS, ie simply writing to memory. So I tried mapping my register area into virtual space (like I do with the mmio area), to no avail. Same result, sig 11. Background info: SiS hardware has a relocated i/o ports area which allows access to i/o ports not only at 0x3xx etc, but also at some other address. In order to make the vgahw module work with these ports instead of the normal ones at 0x3xx, I abuse PIOOffset by adding the correct offset. But no matter whether the vgahw module or my own code accesses the registers, the sig 11 happens anyway. The Linux framebuffer driver works well without mapping this register area (which is at physical 0x4000, FYI). Is there anything special about MIPS that I missed? Well, domain support for MIPS has yet to be written. Ditto for PowerPC. And that for Alpha's is somewhat broken. Lack of time, for one, and lack of hardware. For those who are interested: I have looked into this more closely now and it seems there are two problems: 1) port i/o on MIPS (as on ARM32) is done with memory mapped i/o. The inb/outb macros in compiler.h look smart as they correctly add IOPortBase to the port number, but IOPortBase is not initialized throughout the entire XFree86 code as of 4.4. 2) IOPortBase is declared in compiler.h itself and hence isn't global. Therefore, any module including compiler.h will have to initialize it before using inX/outX. Since the vgahw module doesn't do this, it can't be used. Well. I think I give up for the time being. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Register access on MIPS system
I am having a hard time making the SiS driver run on a MIPS machine. It's some Thoshiba system, with a little-endian CPU. (Under Debian, this goes by the name Mipsel as opposed by the big-endian Mips). The user is running Debian's extremely patched almost-4.4. Current situation: Whenever an i/o register is accessed via inb/outb macros, the X server exits with a signal 11. I checked compiler.h and figured that i/o access (as done via ports on x86), it like MMIO access on MIPS, ie simply writing to memory. So I tried mapping my register area into virtual space (like I do with the mmio area), to no avail. Same result, sig 11. Background info: SiS hardware has a relocated i/o ports area which allows access to i/o ports not only at 0x3xx etc, but also at some other address. In order to make the vgahw module work with these ports instead of the normal ones at 0x3xx, I abuse PIOOffset by adding the correct offset. But no matter whether the vgahw module or my own code accesses the registers, the sig 11 happens anyway. The Linux framebuffer driver works well without mapping this register area (which is at physical 0x4000, FYI). Is there anything special about MIPS that I missed? Anyway, -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] No Xserver with Debian 3.0r2
Morrison Hoyle wrote: I would appreciate any help to get the Xserver working with Debian. I have been told many times that Debian is the best distro so when the Australian Personal Computer Magazine for June 2004 had a free DVD with this distro I had to try it. But after the complete installation has gone apparently perfectly, it makes several attempts to bring up the GUI and collapses with ¨no screens¨. I have been through this several times, always with the same result. Now I have used several other distros and versions and my system has always automatically set up XFree86 so what is wrong with Debian? I have reverted to Mandrake 9.2 for the moment. I attach the Xfree86.0.log file from my Debian attempts. Apologies for the size of this file. My screen is a LG L1512S although Morphix and Knoppix say it is a GSM 3b64. It appears to only want to operate at 1024x768 which is OK with me. The on-board video card is SiS650. I see that Debian 3.0r2 uses XFree86 4.3.0 which is the same as with Knoppix although the kernel versions are not the same. Should I copy the XF86Config and XF86Config-4 files produced by Knoppix and replace those created by Debian? Please help! Log file is attached. This log is not from Debian and I don't see any no screens found errors there. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Problem SIS Card
hasrul wrote: Error Report I don't see a SiS card on this system. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xfree86 sis driver problem
srinivas g wrote: hello experts, i installed ltsp in my redhat linux 8.0 system. and one of my client machines having SIS 6215 video card. when it is booting i am getting the log file . i am sending that log file as an attachment. Please look into the matter and hoping that u will provide the solution to our problem. Wating for ur reply Srinivas. 1. This is no SiS 6215 but a SiS 650. 2. I don't see a problem in this log. 3. RedHat 8.0 is far older than the chip. How about using a more recent version? 4. You are using the vesa driver. A dedicated sis driver for the SiS650 for 4.2 is available on my website. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Fwd: [XFree86] fullscreen modelines
Billy Biggs wrote: I have a problem with tv dvd and video fullscreen with a flat panel LCD 19 SONY in DVI-D. I use by default a resolution 1280x1024 but when I watch TV , DVD and VIDEO I would need 1280x960 otherwise I see 1 horizontal black centimeter on top and bottom of the screen. 1280x1024 flat panels are not 4:3. If you actually did get a 1280x960 modeline to work (which I do not think makes sense), the video would be stretched. The black bars are supposed to be there. I do not think it makes sense to change the resolution of your flat panel, since it is physically a 1280x1024 grid. I have a few 19 Sonys (don't recall the exact model numbers) and they all stretch 1280x960 to 1280x1024 - with a wrong aspect ratio as the result. So you really don't want 1280x960. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] May I ask a question?
Michael Gu (HangZhou) wrote: Dear Sir: After I have make the XFree86 and install it, I should can run XWindows. But after I sent the command startx, the xwindows gives me the interface for KDE and then the cpu and the harddisk run into a busy mode. I can not control my mouse and the computer seems to keep busy forever. Could you give me some hints to deal with the problem? My XFree86 version is XFree86-4.4.0, my operation system is Linux 9.0 and my video card is SIS661. Thank you and best regards, Michael Gu 2004/05/14 XFree86.0.log Use the current driver from my website. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] May I ask a question?
Michael Gu (HangZhou) wrote: Dear Sir: After I have make the XFree86 and install it, I should can run XWindows. But after I sent the command startx, the xwindows gives me the interface for KDE and then the cpu and the harddisk run into a busy mode. I can not control my mouse and the computer seems to keep busy forever. Could you give me some hints to deal with the problem? My XFree86 version is XFree86-4.4.0, my operation system is Linux 9.0 and my video card is SIS661. Thank you and best regards, Michael Gu 2004/05/14 XFree86.0.log Ah... I see you are using the vesa driver. No idea why that one would cause a machine freeze.. Anyway, as said, use the current sis driver from my website instead. If that one causes a machine freeze, too, then the problem is not the video driver. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Sis6326 register unlock problem
harry wrote: Thx for the info, in fact, I guessed that I used a wrong IO port address for sis on Mips, but I don't know where can I find the correct IO address and video memory mapping address. It's both in the PCI config registers. The X driver uses this info anyway - but the version you are using is from Aug 2002 and therefore ancient. Please try updating the driver (source for all versions of XFree86 = 4.1 available on my website). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Please forward 'scanpci -v' output to XFree86 support team
. wrote: XFree86 has found a valid card configuration. Unfortunately the appropriate data has not been added to xf86PciInfo.h. Please forward 'scanpci -v' output to XFree86 support team. here is the output [...] pci bus 0x1 cardnum 0x00 function 0x: vendor 0x1039 device 0x0325 SiS Device unknown CardVendor 0x1039 card 0x0300 (SiS, Card unknown) STATUS0x0230 COMMAND 0x0007 CLASS 0x03 0x00 0x00 REVISION 0x00 BIST 0x80 HEADER 0x00 LATENCY 0x47 CACHE 0x00 BASE0 0xc008 addr 0xc000 MEM PREFETCHABLE BASE1 0xdfec addr 0xdfec MEM BASE2 0xbc01 addr 0xbc00 I/O BASEROM 0xdfeb addr 0xdfeb not-decode-enabled MAX_LAT 0x10 MIN_GNT 0x03 INT_PIN 0x00 INT_LINE 0x00 BYTE_00x6025001 BYTE_1 0x00 BYTE_2 0x806d720 BYTE_3 0x Please advsed asap I would like to get X up soon Update to a more recent version of XFree86 or, if you are running = 4.1, go to my website and download a suitable driver. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Sis6326 register unlock problem
harry wrote: Hi,all I met a problem while porting xfree86 to mips, it seems that I can't unlock the sis6326 registers. SR5 is used as password register in sis6326, if 86h is written into this register, then A1h will be read from this register, and unlock all the extension registers.If the value other than 86h is written into this register, then 21h will be read from this register,and lock all the extension registers. But now when I wrote 86h to this register, I always get ffh, so the display can't be initialized. Is there anyone met this problem? You have more than this locking/unlocking problem. It seems that none of the registers can be written or read, or they are being read from/written to wrong addresses. (For example, the memory clock is never 14 MHz, and there are no 2MB versions of the 6326.). Looks like a general register addressing problem. I have no experience whatsoever with mips hardware, so I can't help you further. You can, however, try the most recent driver from my website. It uses exclusivly relocated i/o ports, so perhaps this helps. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Two graphics adaptors
Frans Andersson wrote: It works now. I'm not quite sure of what I did, but here's the correct XF86Config part: --- Section Device Identifier nvidia0 Driver nvidia BusID PCI:1:0:0 Screen 0 EndSection Section Device Identifier nvidia1 Driver nvidia BusID PCI:1:0:0 Screen 1 EndSection Section Device Identifier card0 Driver s3virge BusID PCI:0:12:0 Screen 0 EndSection --- Note that I use Screen 0 on the S3 ViRGE card, instead of Screen 2. Screen 0 on my nVidia and Screen 1 on my nVidia TV-out. (I also changed the Identifier, but that was not the problem) So I suppose the problem was that I used Screen 2 instead of 1. Correct. See man XF86Config-4: Screen number This option is mandatory for cards where a single PCI entity can drive more than one display (i.e., multiple CRTCs sharing a sin- gle graphics accelerator and video memory). One Device section is required for each head, and this parameter determines which head each of the Device sections applies to. The legal values of number range from 0 to one less than the total number of heads per entity. Most drivers require that the primary screen (0) be present. Emphasis on last sentence. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
MGA driver question
Does the MGA driver initialize the card through int10 if it is secondary display adapter? Reason for asking: A user has a SiS-based box and wants to use both the SiS internal graphics as well as a g200. If the SiS is primary, the mga doesn't seem to get initialized properly (memory clock wrong, memory size only 2048 instead of 8192). Using the card in this state results in severe disturbances on the mga screen (whereas the SiS works fine). If the SiS is secondary, the SiS driver detects this and tries to initialize the card through int10 - but it fails doing so because the int10 module can't find the VBIOS. (This might be related to a system BIOS problem; I think the VBIOS of SiS integrated graphics chipsets is included in the system BIOS in compressed form and uncompressed and written to RAM during boot. I assume that the system BIOS simply does not do that if the internal graphics is to be treated as secondary adapter. Since I don't know the details and a work-around for this, the MGA must be secondary.) The SiS card is unusable uninitialized (and the SiS driver can't simply do that because of customization problems; the VBIOS communicates a lot with the system BIOS and does stuff that is different on each and every machine). Since the MGA driver finds its BIOS even if it secondary, int10 should work I guess... Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA driver question
Thomas Winischhofer wrote: Does the MGA driver initialize the card through int10 if it is secondary display adapter? Reason for asking: A user has a SiS-based box and wants to use both the SiS internal graphics as well as a g200. If the SiS is primary, the mga doesn't seem to get initialized properly (memory clock wrong, memory size only 2048 instead of 8192). Using the card in this state results in severe disturbances on the mga screen (whereas the SiS works fine). If the SiS is secondary, the SiS driver detects this and tries to initialize the card through int10 - but it fails doing so because the int10 module can't find the VBIOS. (This might be related to a system BIOS problem; I think the VBIOS of SiS integrated graphics chipsets is included in the system BIOS in compressed form and uncompressed and written to RAM during boot. I assume that the system BIOS simply does not do that if the internal graphics is to be treated as secondary adapter. Since I don't know the details and a work-around for this, the MGA must be secondary.) The SiS card is unusable uninitialized (and the SiS driver can't simply do that because of customization problems; the VBIOS communicates a lot with the system BIOS and does stuff that is different on each and every machine). Since the MGA driver finds its BIOS even if it secondary, int10 should work I guess... Sorry for replying to my own posting: Option int10 (in the mga Device section) solved the problem, just in case anyone is interested. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Re: Xv and memory
Erik Slagter wrote: Hi, How can I calculate how much memory my frame buffer + Xv will need or actually use? I have a dual head setup on a Radeon Mobility 7500, 16 Mb memory. In my normal setup I have a panel running [EMAIL PROTECTED] and a TFT monitor running [EMAIL PROTECTED] This would imply it needs 1400x1050x4 + 1024x768x4 bytes of memory (+ some overhead), which is approx. 8.8 Mb. I can do all stuff with xv on screen #1, but Xv on screen #0 (the 1400x1050 one) fails with BadAlloc when requesting Xv for resolutions over approx 200x100. I don't understand that, where does all that memory go? I don't know exactly how the radeon driver shares the available memory among the two heads, but if it does that 50:50 as I would assume, the problem is obvious. If each screen gets 8 MB, the 1400x1050x32 screen uses almost 6MB just for the visible screen. A little bit for pixmap cache, mouse cursor, perhaps command queue and the available memory soon isn't enough for Xv (which probably uses double-bufferung for avoing tearing effects). Not even speaking of memory fragmentation after a while. For YV12/I420/NV21/NV12 video, the required memory size for one frame is calculated as follows: Size = width * height * 3 / 2 For YUV2/YUVY/YVYV/RGB5/RGB6 it is Size = width * 2 * height For double buffering, multiply this by 2. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Spawning x based on sis-driver auto detection of available devices
Robert Rozman wrote: Hi, I'd like to do following setup (I have Pundit with sis 651 chipset with two possible output devices): - if I have only first VGA device available I'd like to spawn certain X with Freevo app on this screen certain X? I am afraid I don't follow. - if I have first + second device (TV out) that would spawn X with Freevo app on second device and normal X with desktop on primary VGA. I've read in sis driver manual that if it detects two devices with proper settings it'll spawn two independent X screens - No, it does not. And I can't imagine the manual says so (since I wrote it). *Unless* you configure two device, monitor and screen sections, it will show the same screen on both output devices. If you configure dual head mode (without the Xinerama option), there will be two sessions, each on one output device. I'd just like to specify what to spawn on each device in case of one and in other case of two devices. Is this possible and doable with XF86Config settings or some other utility ? Any examples ? Basically, there are three modes as regards output device handling: 1) Normal - one or two devices detected, both show the same. This is the default unless either a) two device, monitor, screen sections are given, or b) mergedfb (merged framebuffer mode) is enabled (Option MergedFB or MergedFBAuto) 2) Dual head mode: As said, two device, screen, monitor sections are needed, each one for CRT1 and CRT2. Without the option Xinerama, you get two sessions. With Xinerama, you get... Xinerama 3) MergedFB: Works a little like Xinerama. For a detailed documentation, please see my website. Examples for configuration files are there, too. Thomas Sorry for newbie language, I'm just getting started in this area. Thanks in advance, Robert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XVideo fails on 845G @ 1600x1200 (XF86 4.4.0)
Bjorn Solberg wrote: The limit is based on the documentation I had available when writing the driver, and on the fact that exceeding those documented overlay limits would result in a hardware lockup. It is possible that newer hardware revisions have a different physical limit. You'd need to rebuild the driver with the limit check removed/changed and see if it locks up or not when bring up an XVideo window. Great! I'll download the source, find the limit check, modify it, rebuild and try again then. Since video shows fine in the same resolution under Windows XP, then hopefully that means it'll work for X11 as well. The Windows driver came on a separate CDROM with the computer. Are you absolutely sure Windows is using the overlay and is not blitting the YUV data into the framebuffer instead? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XVideo fails on 845G @ 1600x1200 (XF86 4.4.0)
Bjorn Solberg wrote: Thomas Winischhofer writes: Are you absolutely sure Windows is using the overlay and is not blitting the YUV data into the framebuffer instead? No, can you tell me how to tell the difference? Move the video-window quickly around on the desktop. If the video frame lags behind the window placement for a moment, it is the overlay. (Don't expect the delay to be of the same length like under X, it is presumably shorter.) I know that the Windows driver is able to show high-quality DV (and DVD) video at full-screen without any jerkiness. Using -vo x11 or -vo gl for mplayer in X11, I can't expand the window even 20% before the video starts lagging. (But that's more because the X11 rendering is less efficient than Windows, due to its superior capabilities.) The intel XFree86 driver does AFAIK not support YUV blits; I don't even know if the hardware supports it, and if they can eventually be scaled automatically. Without those hardware features (and of course, without driver support), the YUV data first needs to be converted to RGB, scaled, and so on. And that takes ages. Another idea would be to check what the reference memory clock was for the documents David (?) mentioned. I know from SiS hardware, that the overlay capability does not only depend on dotclocks, but also the memory clock. (Intel and SiS are similar in this regard as they both use shared memory) If the memory clock is higher, the limit for overlay use may be, too. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Asus Pundit and xv - what's your experience
Robert Rozman wrote: Hi, I'm recently posting about my problems with Asus Pundit slow xv performance (Suse 9.0, P4 2.4G , xfree 4.4, sis 651 chipset - I get with xvtest around 200 FPS). Obviously I have no obvious options to tackle this problem (Thomas ran out of ideas), so would like to ask about your experiences, troubles, advices with this machine/chipset and xv ? I had working configuration, but then did security upgrades and it didn't work anymore (also after downgrade to previous system). There are some suspects to o_sync wulnerability of Suse systems, but how can I check that (cat proc/mtrr - anything else) ? In my case everything seems fine from logs, just xv performance is bad (x11perf gets better results 400/sec)... Strictly speaking, it is not xv performance but memcpy() performance. I have a pundit myself and I don't experience that problem (using Debian's 4.3 packages) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Asus Pundit (sis 651) : High CPU usage in xv ?
Robert Rozman wrote: Hi, I'm still fighting with high cpu usage in xv extension whem playing media files (xine, mplayer, vlc) under Suse 9.0 , xfree 4.3.0-29 and sis 651 with latest sis drivers. All log outputs seems fine, just xvtest is at low 200 FPS and cpu is hig (30-50%) when playing video that does rescaling. Are there any utities to check what is going on in xv extension (xine-check reports all fine) ? What should I try to find solution ? I'm attaching xvinfo (all other relevant logs are attached to my previous posts) if anything suspicious is in there ? The XV extension is ok. The problem is that the memcpy() inside takes ages on your machine. Since MTRR finally seems to work I suspect you are a victim of the O_SYNC bug (please search the xdevel archives if you want more information). Either update to the newest version of the SuSE packages or to 4.4 Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Asus Pundit (sis 651) : High CPU usage for X in mplayer - are these values sane ?
Robert Rozman wrote: Hi, I'm sending files requested to give proper help. Like I said it seems like Xv is not working (I get lower cpu if I set -vo x11 in mplayer). I suspect that software scaling is going on, but don't know what to do to correct this ( I get CPU for X 40-50% and for mplayer or mythtv frontend about 20%). I have Asus pundit, with P4 2.4 G. I'll appreciate any help, since this is the only major problem left... I have: uname -a - Linux pundit 2.4.21-144-default #1 Fri Nov 14 00:01:36 UTC 2003 i686 i686 i386 GNU/Linux cat /proc/mtrr reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x1c00 ( 448MB), size= 64MB: uncachable, count=1 reg02: base=0xdc00 (3520MB), size= 64MB: write-combining, count=1 reg03: base=0xe800 (3712MB), size= 32MB: write-combining, count=1 reg04: base=0xe140 (3604MB), size= 4MB: write-combining, count=1 Is that from before or after starting X? Do you have a console framebuffer driver running? (WW) SIS(0): Failed to set up write-combining range (0xe800,0x400) The reason for your problem is that, for some reason, MTRR setup fails, although it obviously is supported by your kernel. At the moment I cannot think of a reason for this. Does this warning message go away if you change the amount of video RAM to, say, 32MB in the BIOS setup? (BTW: Why do you set forcecrt1 to false when it appears that you neither have a TV, LCD or secondary VGA connected?) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 and Debian
Ron Johnson wrote: On Tue, 2004-03-09 at 11:41, Alan Hourihane wrote: Basically - upgrade to a later XFree86 version. Your problem, looks like it's a driver bug. You are running XFree86 4.1.0 that's over 2 years old. I'd try either XFree86 4.3.0 or the newly released XFree86 4.4.0. Which means he'll have to upgrade to Debian Sarge, if he has a fast enough internet connection. There are backports of 4.3 for woody. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] .xinitrc, .Xresources, dpi setting
Dexter Filmore wrote: After switching from console login to KDM I noticed KDM igores ~/.xinitrc. Since I have my dpi setting in there, I'd like to know where to set it instead. .Xresources seems appropriate, but I can't find docs about syntax in it. One solution: In /etc/kde3/kdm/Xservers add - dpi 100 in the :0 local line before -nolisten. Just got hit by that myself after upgrading to KDE 3.2. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: SupportConvertXXtoXX
David Dawes wrote:
On Fri, Mar 05, 2004 at 01:38:06AM +0100, Thomas Winischhofer wrote:
What exactly does a video driver have to be able to do if the
SupportConvert32to24 flag is set at calling xf86SetDepthBpp, provided
the hardware supports, for instance, 24bpp (framebuffer depth) only?
It has to use a framebuffer layer that can do this conversion. fb
can, as can xf24_32bpp (if your driver uses cfb). The s3virge
driver is an example that can still be run with the xf24_32bpp
method, and it does the following to figure out what to load:
case 24:
if (pix24bpp == 24) {
mod = cfb24;
reqSym = cfb24ScreenInit;
} else {
mod = xf24_32bpp;
reqSym = cfb24_32ScreenInit;
}
Most drivers use fb these days, and it has support for this built-in,
and enabled automatically.
So it is save just to set these, I assume (since my driver uses fb).
(Just wondered why the *driver* and not the layer taking care of this
has to (not) set these.)
Thanks Mark and David.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: SupportConvertXXtoXX
Mark Vojkovich wrote:
On Fri, 5 Mar 2004, Thomas Winischhofer wrote:
David Dawes wrote:
On Fri, Mar 05, 2004 at 01:38:06AM +0100, Thomas Winischhofer wrote:
What exactly does a video driver have to be able to do if the
SupportConvert32to24 flag is set at calling xf86SetDepthBpp, provided
the hardware supports, for instance, 24bpp (framebuffer depth) only?
It has to use a framebuffer layer that can do this conversion. fb
can, as can xf24_32bpp (if your driver uses cfb). The s3virge
driver is an example that can still be run with the xf24_32bpp
method, and it does the following to figure out what to load:
case 24:
if (pix24bpp == 24) {
mod = cfb24;
reqSym = cfb24ScreenInit;
} else {
mod = xf24_32bpp;
reqSym = cfb24_32ScreenInit;
}
Most drivers use fb these days, and it has support for this built-in,
and enabled automatically.
So it is save just to set these, I assume (since my driver uses fb).
(Just wondered why the *driver* and not the layer taking care of this
has to (not) set these.)
Do you mean the flag? The layer above does not know whether
or not the driver/HW supports a 24 bpp framebuffer. The nv driver,
for example, does not.
Whether or not the hardware does support 24bpp (framebuffer depth, not
talking about color depth) should be determined by setting/clearing
SupportXXbpp. Why the *driver* needs to set SupportConvert is
beyond me. My understanding is that the respective fb layer should take
care of this (if supported) based on SupportXXbpp (especially since the
*driver* does not need to care about this, as David told me. It just
depends on what layer I choose for above the driver level).
But anyway, my question was answered. Seems to be save to set this
obsure SupportConvert32to24 flag if using the generic fb layer.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
SupportConvertXXtoXX
What exactly does a video driver have to be able to do if the SupportConvert32to24 flag is set at calling xf86SetDepthBpp, provided the hardware supports, for instance, 24bpp (framebuffer depth) only? (SupportConvert24to32 vice versa) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SupportConvertXXtoXX
Mark Vojkovich wrote: On Fri, 5 Mar 2004, Thomas Winischhofer wrote: What exactly does a video driver have to be able to do if the SupportConvert32to24 flag is set at calling xf86SetDepthBpp, provided the hardware supports, for instance, 24bpp (framebuffer depth) only? It's expected to support a 24bpp framebuffer. So far, so good. Depth 24/32 bpp will get translated to depth 24/24 bpp. By whom (ie what layer)? Does the video driver in any way need to take care of this? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
; such as automatic selection of virtual screen size, DPI, meta-modes, etc). The SiS driver gives very good results even if one _only_ specifies Option MergedFB. Takes the largest modes for each output device which survived validity checks, calculates virtual screen size, calculates DPI, etc. Don't know if matrox or radeon have similar functionality. For those who don't know: I have written a quite detailed documentation for MergedFB mode on my website (http://www.winischhofer.net/linuxsisvga.shtml#mergedfbmode) which covers all the configuration problems involved. Maybe this helps forming a new configuration concept. However, I don't think we can make it entirely without options in the Device section... I have thought about this for a long time but haven't been able to come up with a better solution yet. (For the sake of completeness: From a driver programmer's point of view, there is quite much to take care of: - HW cursor (especially if the viewable areas overlap) - video (problem for hardware that only has one overlay; this is not as trivial as it sounds) - hardware limitations (eg. max X coordinate for 3D operations, IIRC this was a huge problem for radeon hardware) The reason for mentioning this is that these can become issues for configuration, too.) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
Alex Deucher wrote: I agree. I think metamodes are kind of klunky, but I don't know what a better solution would be off hand. Another thing about the proposed solution is that in many drivers certain configurations are assumed, which can be confusing in the screen setup. For instance in the radeon driver, the DVI/lvds port is always primary. What's the primary? Since I can put the devices left-right or right-left, primary is IMHO only relevant for Xinerama and/or applications drawing fixed conclusions. (And for the record: The SiS driver needs to treat CRT2 as some sort of primary as well, due to order-of-init reasons required by the hardware. CRT2 can be TV, LCD=DVI-D or VGA2=DVI-A. CRT1 can only be VGA. I also need to know all about the configuration for CRT2 before I can eg. calculate the maximum pixel clocks for CRT1, etc etc etc) It might almost be a better idea to work the other way around. standardize the mergedfb backend stuff (pseudo-xinerama, metamode parsing, pointermoded(), etc.) and then just standardize on options for the drivers. Maybe instead of messing with the monitors in the screen section, allow the user to specify them in the device section like Alan mentioned earlier, something like: option crt2monitor Monitor1 That is an alternative, indeed. And it would be much easier to implement since there is no old version-style and new-version-style XF86Config then (which I wouldn't know how to distinguish between). The disadvantage is that you blast the chain of / Monitor Screen ---x \-Device by directly linking the Device and Monitor section. Dogmatically that isn't really beautiful. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
David Dawes wrote: On Tue, Mar 02, 2004 at 01:18:20AM +0100, Thomas Winischhofer wrote: Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. I think the goal here is provide a simpler and more regular method of handling this stuff, but with a basis that is flexible enough to handle expected needs without going through this again in the near future. Clone and zoom are all special cases of a more general monitor layout mechanism, which is really all about how you postion the multiple view ports into the single screen and how you handle mode switching. Allowing these things to be changed/configured on the fly makes it even more interesting, and will go some way to simplifying real-world configuration. Open question: does the newly (or nearly?) standardised Xinerama extension allow for the physical screen layout to be changed at runtime? It needs to for a least this pseudo Xinerama case. Exactly. However, since I found that changing it run-time either has no effect (so with kde) or seriously confuses apps (many examples) I don't do it now. I just calculate a basic setup (based on the orientation and the meta modes) and use this through out the session. It's no problem with Xinerama, it's a problem with the apps. (Or, well, perhaps Xinerama, too, in case it lacks a facility to notify clients of changes which I don't remember) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFAIK, the OSX port uses the same pseudo stuff that we use. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? At what place in the list? Confusing the user is the least we want, especially with that already quite complicated concept of mergedfb. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/29 11:54:15 Log message: SiS driver: Fix 800x600 and low-res modes for 1024x600 LCD panels Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init.h init301.c init301.h sis.h sis.man Revision ChangesPath 1.54 +4 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.49 +25 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.75 +29 -22xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.45 +19 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.112 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.15 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.man ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/27 09:29:25 Log message: SiS driver: Hotfix (PDC typo) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_driver.c Revision ChangesPath 1.185 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/26 01:16:20 Log message: SiS driver: Missing update Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 300vtbl.h sis.h Revision ChangesPath 1.25 +343 -453 xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h 1.111 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/26 07:07:02 Log message: SiS driver: Don't read BIOS values for VB device detection anymore Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_vga.c Revision ChangesPath 1.46 +6 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/26 07:58:44 Log message: SiS driver: - Disallow 512x384 in 480p mode - Change order of default CRT2 devices (VGA2 least priority) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c sis_driver.c Revision ChangesPath 1.53 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.183 +4 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 09:55:27 Log message: SiS driver: Add missing patch Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_dac.c Revision ChangesPath 1.60 +6 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 10:13:45 Log message: SiS driver: - Fix for new BIOS layout on 315 series (650/740) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init301.c Revision ChangesPath 1.49 +8 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.72 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 13:26:04 Log message: SiS driver: PDC detection fix Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_driver.c Revision ChangesPath 1.180 +24 -16xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 14:40:49 Log message: SiS driver: Further fixes for new ROM layout (65x/740) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init301.c sis_driver.c sis_vb.c vstruct.h Revision ChangesPath 1.51 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.74 +8 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.181 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.44 +9 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.35 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 15:22:24 Log message: SiS driver: - Add timing estimation for new LCD resolutions - Don't write BIOS scratch area on non-x86 archs Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 310vtbl.h init.c sis_dac.c sis_driver.c sis_vb.c Revision ChangesPath 1.26 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/310vtbl.h 1.52 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.61 +18 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.182 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.45 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [XFree86] XFree86-4.3 Problem
Yoshikazu Nakamura wrote: Dear Sir, I could not start XFree86-4.3 with FreeBSD 5.2-RELEASE although I did't have any problem when I used XFree86-4.2 with 5.1-RELEAEE. I attached logfile output, and I am happy if you could send me any suggestion. Remove load dri from the Modules section of your config file. DRI is not supported in 4.3, and was never under *BSD. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/16 11:38:25 Log message: SiS driver: - Fix segfault during logout/login - Remove support for a8r8g8b8 alpha textures in RENDER acceleration (not supported properly by hardware) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis310_accel.c sis_driver.c Revision ChangesPath 1.38 +27 -66xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.177 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/16 16:43:57 Log message: SiS driver: - Get rid of overly vain advertising clause in license (and hence switch to 3-clause variant) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 300vtbl.h 310vtbl.h init.c init.h init301.c init301.h initdef.h oem300.h oem310.h osdef.h sis.h sis300_accel.c sis300_accel.h sis310_accel.c sis310_accel.h sis6326_video.c sis_cursor.c sis_cursor.h sis_dac.c sis_dac.h sis_driver.c sis_driver.h sis_opt.c sis_regs.h sis_setup.c sis_vb.c sis_vb.h sis_vga.c sis_video.c vgatypes.h vstruct.h Revision ChangesPath 1.24 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h 1.24 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/310vtbl.h 1.47 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.47 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.70 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.43 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.33 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.15 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/oem300.h 1.25 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/oem310.h 1.9 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/osdef.h 1.109 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.28 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.c 1.20 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.h 1.39 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.18 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.18 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis6326_video.c 1.28 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.16 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.h 1.58 +1 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.19 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.h 1.178 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.37 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.56 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.28 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_regs.h 1.30 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c 1.42 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.16 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.h 1.44 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.49 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c 1.22 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/vgatypes.h 1.33 +2 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: SiS driver
Kean Johnston wrote: All, Is there any reason why the SiS driver isnt the one Thomas Winischofer provides on his site? I recently had very negative experiences with the stock SiS driver on a 661FX that his driver solved immediately. Now I realized it may have solved just this one problem but it seems as the one on his site gets more attention. I know Thomas has submitted other fixes into the tree, and may even be the SiS maintainer. I am, and the current SiS driver (well, more or less) is in CVS (since I have write access). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.0 status update
David Dawes wrote: On Sun, Jan 25, 2004 at 09:28:27PM -0500, David Dawes wrote: XFree86 4.4.0 release status update. I'm planning to tag the third 4.4.0 release candidate (4.3.99.903) within the next week. This was delayed by the licence discussion. I'm going to tag 4.4.0 RC3 (4.3.99.903) tomorrow. What's the estimated release date? I have quite a big SiS driver update in the queue which MUST go into 4.4 otherwise it is useless on newer chipsets. Just need to do some testing first which would take about a week. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Driver
Jerry robards wrote: Is there a driver update for sis 5598/6326? Jerry Robards www.winischhofer.net/linuxsisvga.shtml -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] problem with modelines
Andreas van Leeuwen Flamino wrote: On Wed, Feb 11, 2004 at 11:22:30AM -0800, Mark Vojkovich wrote the following (indented); We need to see the /var/log/XFree86.0.log file. Mark. I have attached it to this message. You are using depth 8 for which there is no Display SubSection in the config file you sent previously. (==) R128(0): Depth 8, (==) framebuffer bpp 8 (II) R128(0): Pixel depth = 8 bits stored in 1 byte (8 bpp pixmaps) Insert for example DefaultDepth 16 before the first Display subsection. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: a8r8g8b8
Mark Vojkovich wrote: What's the question/problem? Where might this bug be at home? By bug I mean that red and blue are always the same, which they obviously shouldn't. By at home means in what part of the XAA (?) source should I start looking? Thomas Mark (and others), I played a little with a8r8g8b8 alpha textures and despite the fact my driver (erm, by hardware reasons) can't accelerate them, I think I found an issue: (I use a source where these kinds of alpha textures are still accepted by XAA, ie before Mark disabled this). The textures always have identical red and blue alphas. Green is ok, though. I have no idea where to look for this... any hint? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] problem with modelines
Andreas van Leeuwen Flamino wrote: Hello, After configuring my XFree86 4.1.0.1, i keep on getting a 1920 by 1440 screen. I have tried to correct this by entering the modes lines to my XF86Config. However, i still get 1920x1440. SubSection Display Depth 15 EndSubSection SubSection Display Depth 16 Modes 1600x1200 1280x1024 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 1600x1200 1280x1024 800x600 640x480 EndSubSection EndSection Can anyone tell me what i have missed or give me a pointer to the documentation covering a solution for my problem? Edit /etc/X11/XF86Config-4, not /etc/X11/XF86Config. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
a8r8g8b8
Mark (and others), I played a little with a8r8g8b8 alpha textures and despite the fact my driver (erm, by hardware reasons) can't accelerate them, I think I found an issue: (I use a source where these kinds of alpha textures are still accepted by XAA, ie before Mark disabled this). The textures always have identical red and blue alphas. Green is ok, though. I have no idea where to look for this... any hint? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] BUG
kaustubh wrote: I have installed RED HAT LINUX 7.2 on my Pentium2 233 with 64MB RAM.I have SiS6215C as my display card. I am unable to run X Server.I am attaching the LOG file herewith. Plz.give me an URGENT solution. Thanks. This card is not supported by the SiS driver. Replace driver sis by driver vesa. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] core dump when configuring
[EMAIL PROTECTED] wrote: Aloha I have been having some problems getting XFree86 configured on one of my systems. I have read and followed the handbook to the best of my ability with no success. My system is a Mercury mainboard with a SiS 630e chipset and a 1GHzPro processor. I have an Adaptec AHA-2940UW scsi interface with an 18GB Western Digital HD connected. I am installing from a FReeBSD 5.2 Cd that was downloaded and burned properly. The MD5Sum was checked before burning. The SiS630 Chipsetincludes an integrated 128-bit 2D/3D graphics accelerator. The graphics system uses the Ultra-AGP architecture and uses a shared memory scheme that allows up to 64 MB of system memory to be used as video memory. The most recent attempt I installed FReeBSD 5.2 with XFree86 and did not set it up during install. After rebooting, I did an: #XFree86 -configure all seemed to go well and XF86Config.new was created in /root. I then did: XFree86 -xf86config XFree86Config.new An attempt is made and the the program crashes and the core is dumped in /root as XFree86Config.core. I have attached the file /var/log/XFree86.0.log for your benefit. Thank you in advance for your help. Robert Marella P.S. I have tried several times to set up XFree86 during install. I always got the dialog box that stated XFree86 failed, would you like to try again. YES NO Remove ther Load dri statement from your XF86Config. DRI is not supported in 4.3 anyway. And go to www.winischhofer.net and get a newer driver while you're at it. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Can't work with SiS 300 on XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2)
Rahul Ramchandani wrote: Hi I tried installing Red Hat 9.0 on my P4 system ( 256 MB RAM, 40 GB HDD, 256K cache). However, not only does the installer not auto detect my graphics card, it also does not even work when I explicitely specify it towards the end of the installation. I have a SiS 300 graphic chip and am using XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2). I wonder if it is a bug or some problem on my end. The latter. You're using the wrong driver (vga) instead of sis. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
Egbert Eich wrote: Sven Luther writes: Maybe a decision on both parts on this would be ok ? XFree86 could make sure the licence of the driver code would not conflict with the GPL, keeping the old one for example, and the fbdev driver authors would dual-licence the code, both GPL and the old xfree86 licence would do just fine. Benjamin, what do you think about this ? BTW, CCing this to the linux-fbdev mailing list. Yes, a personal agreement between driver developers would also work. However they tend to change and other people will make contributions who all would have to agree also. I don't know if a general dual license agreement in the kernel file header would be possible. Yes, it is. See the current SiS driver source files. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
Andrew C Aitchison wrote: As I remember it, the pertinent register information here was reverse engineered, so it is at least arguable that I'd be copying fbdev intellectual property here if I'd extracted and reused it. Perhaps I was wrong, but my understanding from my days in a software house taught me that I'd be breaking copyright not just by lifting lines of code, but also by reading the code and copying intellectual property, including register information. I hardly think that pure numerical data like register contents can be subject to copyright anyway. Copyright only covers the very (code) implementation. If your code _does_ the same but though a somewhat different implementation, it might be infringing eventual patents but not copyright. Besides there are only a few ways of writing code to twiddle a bit in a register - I could easily duplicate a line of code while reconstructing it from the register description, and it would be hard to prove that I didn't just copy the line directly. If (parts of) the implementation is (are) obvious and carries/y no creative element whatsoever (like setting/clearing a bit in a register), and/or is the only way, copyright does not apply either. Otherwise no one could write any new driver for any hardware. In simple terms, you can't infringe copyright by copying stuff like a = b or setregister(register, value). Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
Dr. Rich Murphey wrote: You can take an XFree86 driver, regardless of what the copyright says, and completely rewrite it as an fbdev driver (which is what I believe usually happens) and this is not a violation of the XFree86 copyright or even of the GPL. Copyright doesn't apply to ideas or algorithms in a work. It's not a patent. It only applies to the reproduction of the code. Mark. Those are valuable comments, but just to highlight some distinctions, here's a common analogy... If we both take a picture of the grand canyon and copyright it, each can be distributed without infringing the other. If you record a country-western song, and I listen to it and record it as a jazz ballad, do you deserve acknowlegement? If the melody is the same, yes. However, a melody is no algorithm, it's a creative work in the area of music (which is positively covered by copyright law, while algorithms and ideas are not). Software has been considered a creative work of literature for a long time until many countries expressedly added software to the list of creative works in copyright law. However, only the very implementation is covered and protected, not the idea behind it. The idea (or the algorithm) can only be protected by patent law in a few countries like the US and Japan. Pure data (like some C headers and register contents table) are neither an idea nor software, hence not copyrightable. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fall back drivers?
Jerry Haltom wrote: Ahh! I hadn't checked any of the work in 4.4 before I came up with this idea. This is wonderful. What about in the case of a broken driver where the X server is unable to start? I don't know of any driver that is broken in a way that keeps XFree86 from starting. How the display looks is a different story, though (and this case can hardly be detected) One of the main problems I've seen Is when somebody breaks their X config, either by running some driver installation (nvidia-installer yay!) or recompiling their kernel and leaving off a third party module results in a non working X. I don't know how far David has come, but I think that would be possible. PreInit() already returns a Bool, so it should be easy to fall back at that stage. The same basically applies to ScreenInit(). Users would definitely would rather be at a 640x480 display running in 16 colors than a login console prompt. Frankly, I don't think a 16 color 640x480 display is helpful as long as there is no GUI killer-tool for reconfiguring XFree86 for this kind of users. (Such users presumably also run KDE or Gnome, and at least KDE does not like 16 colors that much...) But anyway, the fallback idea is a good one IMHO. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] How to reduce the over head of one bit appending in 24 bit RGB image display?
Mark Vojkovich wrote: A couple drivers support that but most do not. The reason why is that it's generally a bad idea. If you change the XImage format to 24bpp, many desktop applications will break. Also, performance is sometimes slower than with 32bpp due to alignment issues. See the Option Pixmap described in the man page on XF86Config. Note, most drivers don't support this. ... and some hardware doesn't either. Thomas Mark. On Fri, 30 Jan 2004, Subbiah wrote: Hi, I am getting the RGB value of the image in 24 bits. So I have Started my application in 24 bit color depth. I am planning to use the XPutImage function for displaying the RGB value of the images. My application reports the depth as 24 but the bpp ( bits per pixel ) as 32?. So for my Ximage, I need to append one bit of information to get them in 32 bits. Is there any way to set the bpp as 24, so that My overhead on the one bit appending on each RGB value will go off. Thanks. With Regards, L. Subbiah ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/27 03:58:27 Log message: SiS driver: - Improve RENDER acceleration by supporting source alpha and PICT_a8r8g8b8 format (however, component alpha is not supported yet) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.h init301.h sis.h sis310_accel.c Revision ChangesPath 1.46 +0 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.42 +0 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.108 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.37 +83 -25xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Another Render question
Can anyone explain the meaning of a8r8g8b8 pure alpha textures? The two hooks for render acceleration are a) CPUToScreenAlphaTexture (should be PICT_a8) b) CPUToScreenTexture (like eg PICT_a8r8g8b8) a) is used for aa text; however, sometimes (haven't yet found out why) the alphaType argument to this is not PICT_a8 as one would expect, but PICT_a8r8g8b8. I don't quite get the logic behind this. What's the CPUToScreenTexture hook for if CPUToScreenAlphaTexture should be able to deal with ARGB textures? And how should the red, green and blue arguments correlate with the RGB contents of this odd texture? I extended RENDER acceleration in the SiS driver now to seemingly correctly handle such ARGB alpha textures textures as well; I simply ignore the RGB part of an ARGB alpha texture fed to CPUToScreenAlphaTexture; but my curiousity WRT if this is the idea behind it remains. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Status?
Kendall Bennett wrote: Clearly the future of XFree86 is very murky right now, as many developers have left to work on other projects such as freedesktop.org, and now with the core team disbanded it is unclear exactly how companies such as SciTech or vendors such as ATI, Via, SiS etc who do not have direct connections with someone on the XFree86 committer list can get their patches into XFree86. Offtopic: From my experience with SiS and the quality of their code (if it deserves that name), I seriouly hope they don't at all. And BTW, they have contact with me. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: On Mon, 26 Jan 2004, Thomas Winischhofer wrote: Can anyone explain the meaning of a8r8g8b8 pure alpha textures? It's probably a bug that XAA is letting those through. a8r8g8b8 alpha masks mean one of two things: 1) If componentAlpha is set, it's 4 alpha masks which act separately on the different components of the source. 2) If componentAlpha is not set, you're supposed to just use the alpha portion. OK, I see. I didn't analyze the code deeply enough. In my tests, the RGB portion of the a8r8g8b8 formatted alpha texture was always zero. (Qt in some way [indirectly] uses this to draw aa text, as does x11perf -aaXXtest; stangely, I had this accelerated a while back WITHOUT allowing a8r8g8b8 but ever since I installed Debian's experimental packages with external libxrender and libxft the accelerated path wasn't used. Despite that I recompiled these external libs against 4.3 headers.) I do now understand that r, g, b can contain separate alpha values for each component (which I easily could support in my driver since I first need to build an accelerator-suitable texture anyway). What is supposed to happen with the 4th, the a component? XAA's render support was written in the early days of render, back when render didn't support as much stuff as it does now. It probably makes sense for XAA to only pass them through when componentAlpha is not set, then it would be up to the driver to decide whether or not it can just extract the alpha portion, and punt if it doesn't. We should probably be adding if(pMask-componentAlpha) return FALSE; right after the if(pMask) test to reject the 4-component alpha condition. What if some hardware supported this? Wouldn't it be better to set a flag in the Flags field submitted to the driver's SetUpCPU...() function? Or/and perhaps let the driver specify a flag in the CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: What if some hardware supported this? Wouldn't it be better to set a flag in the Flags field submitted to the driver's SetUpCPU...() function? Or/and perhaps let the driver specify a flag in the CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT? If you want to test that, you can add it, though I'd recommend waiting until after 4.4. I've already checked in code that has XAA bail out when it sees componentAlpha. In order to avoid breaking binary compatibility, you'd need to add a flag to the CPUToScreenAlphaTextureFlags that allows the driver to say that it supports per-component alpha. Otherwise all the current drivers would need to be rewritten to recognize the new flag. That's basically what I meant. I will commit my changes to the sis driver anyway (just adding support for nonComponent a8r8g8b8), but wait with the rest. Thanks. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Sottek, Matthew J wrote: a) is used for aa text; however, sometimes (haven't yet found out why) the alphaType argument to this is not PICT_a8 as one would expect, but PICT_a8r8g8b8. I don't quite get the logic behind this. What's the CPUToScreenTexture hook for if CPUToScreenAlphaTexture should be able to deal with ARGB textures? And how should the red, green and blue arguments correlate with the RGB contents of this odd texture? a) Is used whenever you want to combine a per-pixel alpha with a diffuse color. Text, as you said is the common case but I think there were other intentions... I've seen some screenshots on Keith's site that show using a window's own alpha channel as a drop shadow. In order for that to work you would need to get an argb input (the offscreen copy of the full window contents) but only use the a and use the diffuse rgb as provided. Maybe that is the intended use? Hm. I _think_ we're talking about the same thing. However, my (second) question was more meant in the line of the following: I am given a constant r, g and b as each a separate parameter, and an a8r8g8b8 texture which by Mark's explanation is for providing an alpha value for each of the r, g, b components. But the format is _a8_r8g8b8; if the components' alphas are in the r8g8b8 part, what's to happen with the a8 part of that texture? Formula, anyone? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another Render question
Mark Vojkovich wrote: On Mon, 26 Jan 2004, Thomas Winischhofer wrote: Sottek, Matthew J wrote: a) is used for aa text; however, sometimes (haven't yet found out why) the alphaType argument to this is not PICT_a8 as one would expect, but PICT_a8r8g8b8. I don't quite get the logic behind this. What's the CPUToScreenTexture hook for if CPUToScreenAlphaTexture should be able to deal with ARGB textures? And how should the red, green and blue arguments correlate with the RGB contents of this odd texture? a) Is used whenever you want to combine a per-pixel alpha with a diffuse color. Text, as you said is the common case but I think there were other intentions... I've seen some screenshots on Keith's site that show using a window's own alpha channel as a drop shadow. In order for that to work you would need to get an argb input (the offscreen copy of the full window contents) but only use the a and use the diffuse rgb as provided. Maybe that is the intended use? Hm. I _think_ we're talking about the same thing. However, my (second) question was more meant in the line of the following: I am given a constant r, g and b as each a separate parameter, and an You are also given a. a8r8g8b8 texture which by Mark's explanation is for providing an alpha value for each of the r, g, b components. But the format is _a8_r8g8b8; No, it modulates r, g, b, and a. if the components' alphas are in the r8g8b8 part, what's to happen with the a8 part of that texture? You are given constant a, r, g, b. An a8 texture modulates all of them: ... unless XAA_RENDER_NO_SRC_ALPHA is set...? a *= a8 ... in which case the above does not apply...? r *= a8 g *= a8 b *= a8 Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/24 13:29:21 Log message: SiS driver: - Remove debug output - Clean up Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c sis_driver.c Revision ChangesPath 1.46 +31 -46xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.176 +0 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [XFree86] removing 'blue-screen' produced by libXv
dave giffin wrote: I'm using mplayer with the 'xv' video output (which uses XFree86's libXv to render the video onto the screen). But, when it first comes onto the screen, or when I move the window, there is a blue-screen for a moment until mplayer updates the display. I would like to be able to change this from blue to black. I've asked mplayer developers for help and they've suggested I ask xfree86 developers. Any thoughts as to where in libXv to look? Simple. Change the colorkey to black. Nearly all (if not all) drivers know a XV_COLORKEY property for doing this. Interesting that mplayer developers need to point you to this list... Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/21 03:40:12 Log message: SiS driver: - Longer delay before switching on LCD backlight after mode switch Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c sis.h Revision ChangesPath 1.66 +1 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.105 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/21 03:46:00 Log message: SiS driver: - Add longer delay for LCD backlight to DPMS code, too Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c Revision ChangesPath 1.67 +2 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/21 14:06:11 Log message: SiS driver: Fix typo Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.h sis_setup.c Revision ChangesPath 1.43 +0 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.28 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/21 14:13:20 Log message: SiS driver: Fix typo Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_vb.c Revision ChangesPath 1.40 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/19 12:07:37 Log message: SiS driver: - Fix Xv bug (incorrect display of large videos when switching output devices) - Add proper 301C TV scaling (using 301C enhanced scaler) - Add aspect ratio support for YPrPb TV output (301C only) - Fix various YPbPr bugs (YPbPr still untested though) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init.h init301.c init301.h initdef.h sis.h sis_dac.c sis_driver.c sis_driver.h sis_opt.c sis_vb.c sis_vga.c sis_video.c vstruct.h Revision ChangesPath 1.44 +16 -45xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.42 +27 -13xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.65 +156 -93 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.40 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.30 +18 -13xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.104 +34 -26xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.55 +16 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.173 +256 -200 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.34 +227 -0xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.54 +37 -6 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.39 +42 -15xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.42 +124 -87 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.47 +2 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c 1.30 +4 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/12 04:40:07 Log message: SiS driver: - add support for YPbPr (HDTV) for 315 series - add 301C support for 315 series Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c initdef.h oem310.h sis.h sis_driver.c sis_opt.c sis_vb.c Revision ChangesPath 1.64 +71 -75xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.29 +6 -6 xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.22 +20 -59xc/programs/Xserver/hw/xfree86/drivers/sis/oem310.h 1.103 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.172 +29 -9 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.53 +6 -6 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.38 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
Yukun Chen wrote: Hi All I am a developer from XGI Technology which is a new company stem from graphic dpt. of Trident and graphic dpt. of Sis. Now we want to share our linux 2D driver with open source community. Then what should we do? Pls give some advice or suggestions. Thanx a lot. Hi, welcome to open-source development! It's pretty easy. Have a look at the existing drivers to find out about the internals of the driver model. And publish the source. Someone will pick it up, review it and eventually merge it with XFree86 CVS (as has happended with the via driver recently). Please, please, please DO NOT produce a driver which is a patch for an already existing driver. This means especially that I (as the author and maintainer of the SiS driver) will not merge XGI support into the SiS driver, despite the fact that some of your current hardware might be compatible to existing SiS hardware. The SiS driver is already big enough. But of course, nobody says that you can't base your driver on the SiS driver (as an example for that matter). For more general issues, somebody else might stand up and speak? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Kde (3.1.3) desktop does not resize to match the screen when changed in portrait mode.
Mark Vojkovich wrote:
With the CCW option, the server should look exactly like
it has a 768x1024 root window from the client's point of view.
What does xdpyinfo say about the screen dimensions.
Mark.
PS. You have to disable the RandR extension to make rotation work
properly. That's Option RandR FALSE in the Section
ServerFlags, I think.
Just a suggestion: Why doesn't the nv driver do this itself it it's very
own Rotate option is set?
if(pNv-Rotate) {
xf86DisableRandR();
}
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/07 13:08:51 Log message: SiS driver: - HWCursor: code re-written and fixed for 661 - HWCursor: Use doublebuffering for flicker-free cursor animations - Fix log-out-hang on 661 Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init301.c sis.h sis_cursor.c sis_cursor.h sis_dac.c sis_driver.c sis_vb.c vstruct.h Revision ChangesPath 1.43 +11 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.63 +99 -50xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.102 +5 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.26 +352 -355 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.14 +112 -221 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.h 1.54 +5 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.171 +48 -13xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.37 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.29 +4 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/03 12:08:05 Log message: SiS driver: - Add YPbPr and HiVision TV output support (660 series) - Update license terms Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: 300vtbl.h 310vtbl.h init.c init.h init301.c init301.h initdef.h oem300.h oem310.h osdef.h sis.h sis300_accel.c sis300_accel.h sis310_accel.c sis310_accel.h sis6326_video.c sis_accel.c sis_accel.h sis_common.h sis_cursor.c sis_cursor.h sis_dac.c sis_dac.h sis_dga.c sis_dri.c sis_dri.h sis_driver.c sis_driver.h sis_opt.c sis_regs.h sis_setup.c sis_shadow.c sis_shadow.h sis_vb.c sis_vb.h sis_vga.c sis_video.c vgatypes.h vstruct.h Revision ChangesPath 1.21 +37 -23xc/programs/Xserver/hw/xfree86/drivers/sis/300vtbl.h 1.21 +37 -23xc/programs/Xserver/hw/xfree86/drivers/sis/310vtbl.h 1.41 +96 -53xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.40 +69 -23xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.61 +460 -390 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.38 +81 -48xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.27 +69 -35xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.12 +37 -23xc/programs/Xserver/hw/xfree86/drivers/sis/oem300.h 1.20 +44 -24xc/programs/Xserver/hw/xfree86/drivers/sis/oem310.h 1.6 +43 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/osdef.h 1.100 +60 -33xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.25 +12 -14xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.c 1.17 +8 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis300_accel.h 1.34 +8 -10 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.15 +8 -9 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.15 +8 -11 xc/programs/Xserver/hw/xfree86/drivers/sis/sis6326_video.c 1.36 +8 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.c 1.10 +8 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_accel.h 1.3 +7 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_common.h 1.24 +47 -66xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.12 +7 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.h 1.52 +10 -10xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.16 +10 -10xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.h 1.12 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dga.c 1.40 +26 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.c 1.11 +28 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.h 1.168 +154 -96 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.32 +10 -9 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.51 +46 -28xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c 1.25 +13 -10xc/programs/Xserver/hw/xfree86/drivers/sis/sis_regs.h 1.26 +9 -9 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c 1.9 +8 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_shadow.c 1.7 +10 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_shadow.h 1.35 +83 -34xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.13 +8 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.h 1.40 +9 -11 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.45 +14 -19xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c 1.19 +41 -23xc/programs/Xserver/hw/xfree86/drivers/sis/vgatypes.h 1.27 +43 -22xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/01/03 12:20:42 Log message: SiS driver: Log fix Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_driver.c Revision ChangesPath 1.169 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
