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: 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: 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
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: 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: 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
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: 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
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: 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
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: [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
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
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: Help: gdb xfree86 video card driver on rh9
harry wrote: I am debuging a video card driver on XFree86.I was using gdb 5.1.1-2.0xfree on radhat 9.0. And I had tried : (1) I was using gdb /usr/X11R6/bin/XFree86 , then run. It result as Segmentation fault. (2) During build sis_drv.o, I had using para -g for gcc. startx open Xwindow fristly, then using ps ax gets the processid of X :0. use SSH login and gdb /usr/X11R6/lib/modules/drivers/sis_drv.o processid. By this way, i could see source codes and function symbols of the sis_drv.o , and could set breakpoints. But Xwindow will not break at those points that i setted.What's wrong on my ways to debug video driver of xfree86 bu gdb? Now i only could use print message to debug,but that is troublesome. If anybody has some suggestion as how to debug I would gladly appreciate any suggestions. Nice to see that a SiS employee is dealing with XFree86. I am no gdb expert myself, but here is my $.02: 1) You need a patched gdb which is capable of dealing with XFree86's modules. I don't have a link at hand, but I'm sure someone else reading this has. 2) If you want to attach to the running XFree86 process: sis_drv.o is not the process, but part of the X process. You need to attach to the X process. In case you are debugging the official XFree86 sis driver, I'd appreciate if you told me what problems you experience (since I am the author and maintainer of this driver). 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: [PATCH] Radeon Xv gamma support
Andrew C Aitchison wrote: On Fri, 19 Dec 2003, Alex Deucher wrote: This patch adds two new XV attributes: XV_COLORSPACE and XV_GAMMA. XV_GAMMA lets you adjust the gamma of the overlay to 8 presets: 0 - gamma 1.0, default 1 - 0.85 ... ... 7 - 2.5 Please let me know if you have any suggestions or find any bugs with this code. The patch is against DRI cvs, but should apply pretty easily to xfree86 or gatos as well. Can I suggest that the API exposes the options in some device neutral manner - ideally a float - which the driver converts to the nearest available preset. Either nVidia or the next generation Radeon is bound to use 16 presets, or calculate the table for an given gamma ? Unless the preset list of gamma values follows some standard (sorry if it does) applications should be able to ask for the value they want, and have something sensible happen ? I think floats isn't possible via XV properties. But I have another suggestion (based on the assumption that you can handle separate gamma values for r, g, b): Make three properties (such as for example XV_GAMMA_RED etc) and allow a range from 1000 to 1, which is the desired value * 1000. 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 master cvsup server refuses authentication
Mike A. Harris wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. David Dawes posted a message about this to [EMAIL PROTECTED] on Nov 2nd. 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 master cvsup server refuses authentication
Mike A. Harris wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. David Dawes posted a message about this to [EMAIL PROTECTED] on Nov 2nd. I've *never* been subscribed to [EMAIL PROTECTED], which was a closed and private list always, and not ever open to public subscription. That list, as far as I know, is strictly limited to people who have CVS write permission. So obviously, the message never reached the full list of people who had access to the master cvs/cvsup server. Sorry, I didn't know how deeply you're involved (or not involved, for that matter) in development. I just meant to give you a hint, and if David didn't post this on devel or xfree, I'd have assumed he had his reasons (which is why I didn't forward his message to you/this list - and no, I'm not the one making up secrets here). Hm, I really should shut up when it comes to political issues here... (take this as a note to self, so to 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 4.4.0 RC1
David Dawes wrote: On Sat, Dec 13, 2003 at 03:06:27PM +, Thomas Estaben wrote: I am testing this release under Gentoo. In my XF86Config, i set up XkbModel to be pc105 and XkbModel to fr. My problem is that the key doesn't work, XFree seems to take pc104 by default without using my settings. I have to use setxbkmap -model pc105 by hand to use this key wich is pretty annoying... Is this a configuration problem or a known bug ? If you really have XkbModel set to both pc105 and fr, then that may be the problem. XkbModel should be pc105 and XkbLayout should be fr. If that still doesn't work, what does 'setxkbmap -print' report? You perhaps running something like KDE overruling the settings from the config file? Happened to me once, took me hours to find out... 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: Experimental Snapshot v4.3.99.901 - SIS-DRI-Driver-Problem
Raymond Jennings wrote: Direct3D may be more than a 3D graphics API...It may ALSO be a hardware interface standard. A given graphics card, might, if I may, speak D3D-ese and/or GL-ese, if you know what I mean. I recommend that the hardware driver guys investigate this, and if this IS true (D3D-ese vs GL-ese), then I suggest we put out a D3D API similar to Mesa, or we could put in a GL-to-D3D translation module. (this could also be vice versa, D3D-to-GL, because D3D retained mode is pretty dang useful, what with its frames and meshes, very nice automatic geometry handling) A D3D API may alsp be useful, and as XFree86 becomes more popular (and I'm sure it will), D3D programmers may have difficulty migrating to OpenGL, and a D3D API would help that. I just hope DirectX isn't an MS trademark, It is. or that they've copyrighted the API...That sounds like something Micro$oft might do. Copyright only applies to a specific code implementation (I think even in the US), however, I think this might be more a software patent issue (just US yet). And porting over MS APIs is no good idea in general 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: Experimental Snapshot v4.3.99.901 - SIS-DRI-Driver-Problem
Eric Anholt wrote: On Sun, 2003-12-07 at 02:27, Andreas Allacher wrote: Hi, I have tried your latest Snapshot and have a problem using the SIS-DRI-Driver at WineX if it comes to Direct3D games OpenGL games work perfect also DirectDraw... BUT as said Direct3D games lock-up (only mouse works still) before I get shown anything the same is for the videos in the game this all worked perfect with the old SIS-Driver but there I had the problem that in any game if DRI was used - I got a lock-up, even TuxRacers [...] I'm having a hard time parsing you here. So with the old driver all games caused a lockup but with the new driver only D3D games in WineX do? Andreas asked me privately about this a couple of times, and I think the problem he's having boils down to - WarCraft III (via WineX) is too dark, possibly meaning the the game playfield area is all black while the game controls and status displays still display OK (is WarCraft III really using DirectX or Direct3D?) - he had lockups with the old driver (which I personally experienced only a very few times) He has never told me wether or not native DRI applications work for him the current driver (apart from the gfxgears statement below). One other thing: with glxinfo I got about 375 FPS with the old driver with the new I get around 200FPS is it still that fast as the old but only glxinfo detects it wrong?. I don't remember at this point any decisions I made that would cause significant slowdowns. (I assume you are talking about glxgears here) I have received reports telling my it's even faster with the new driver. (I don't have a 630 to test this at the moment) 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: [PATCH] radeon Xv alpha blending support
Alex Deucher wrote: The attached patch adds alpha blending support to the video overlay on radeon hardware. It's been tested on my 9200. It adds three new Xv attributes: XV_ALPHA_MODE, XV_GR_ALPHA, and XV_OV_ALPHA. XV_ALPHA_MODE - (0 or 1) selects the alpha blending mode. right now it only supports key and global modes, per-pixel can be added later. 0 is key mode, 1 is global mode. Key mode blends the overlay or graphics layer with the colorkey. Global mode blends the graphics layer and the overlay. XV_GR_ALPHA - (0-255) set the alpha level of the graphics layer (everything but the overlay) (applies to either mode) XV_OV_ALPHA - (0-255) set the alpha level of the overlay (applies to either mode) The patch is against DRI cvs, but should apply pretty easily to any tree. I'm not 100% clear on the function the first two fields of OV0_KEY_CNTL, perhaps someone out there could explain it to me. see my comments in the code. let me know if you have any comments or questions. Is it worth opening a bug in bugzilla for this? The patch and binaries also are available here: http://www.botchco.com/alex/radeon/xv_alpha/ Look out for an improved Xv gamma patch soon. Alex, while you are at it, does the radeon hardware support chroma-keying? (Chroma keying means the overlay is shown if the _video_ color is within a certain range. Chroma-Keying is extremely useful for creating blue-box like effects, like for example people in front of a blue background, which is being replaced by the graphics at playback time). If so, you might want to take a look at the sis driver. Besides, the sis driver also has a property named XV_DISABLE_COLORKEY to avoid the problem of the colorkey always drawn. This works more or less by 1) disabling the colorkey in the video code, and 2) by ignoring accelerator fill-commands with the colorkey as foreground color. Of course, this is no bullet-proof method, but perhaps this is helpful for you, 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: [PATCH] radeon Xv alpha blending support
Alex Deucher wrote: radeon has an option XV_AUTOPAINT_COLORKEY that enables or disables the auto filling of the colorkey by the driver (stops xf86XVFillKeyHelper()). is this equivalent to what your option does? Not entirely. AUTOPAINT_COLORKEY does not stop applications from drawing the colorkey themselves (as, I think, for example Xine does). That is done by the accelerator engine, that checks the color given to the fill functions. (Granted, this only works if the accelerators are on, but who is using a [working] driver without acceration these days) 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: [PATCH] radeon Xv alpha blending support
Alex Deucher wrote: This is probably due to my limited understanding of writing Xv apps but how do you keep the app from drawing the colorkey itself? isn't it I simply assume that the app will, some way or the other, in the end use the XAA accelerator functions. As I said, my method is not bullet-proof. just an X rectangle? is there an Xv function that the app uses or does it just draw a rectangle and paint it the colorkey color? How does the sis driver do it (if it does)? what does the output look like with no colorkey drawn? The depends. Earlier versions of mplayer (0.9) left the background visible (ie didn't overwrite the window at startup); later versions paint the window black at start, for what reason ever. The real application for this feature is, of course, not a generic app like mplayer but a specially written app that utilizes the blue-screen technique for displaying a background and a video which is chroma-keyed, such as a weather forecast where the presenter stands in front of a blue wall and the viewer sees a weather map instead of the blue background. A real-life application of this kind (using SiS hardware and my driver) is installed at a local government's exhibition in Austria; visitors are presented a virtual TV interview person on screen and are being filmed during that interview. Afterwards they can watch the interview (which is being cut in real-time) and see themselves in a beautiful TV studio, while the cabin where the interview took place has a simple plain green background wall.) does Xv even work without a colokey? Yes, at least on SiS hardware. There are 16 combinations of src and dst combination (video-ROPs) available, include the standard one (video if background = colorkey) and all possible combinations of chroma- and colorkey (which monstly aren't so useful after all). I thought that's how the overly worked it overlays the video data based on regions painted with the colorkey. That's one of 16 possible ways. I suppose in global alpha mode though (on radeon), it will blend the video with whatever the graphics layer shows so if I could get rid of that rectangle of color, I'd get a nice blend with the desktop and any windows over or under it. I think it will be like that: If the alpha stuff is activated, the video overlay doesn't care about the colorkey anymore. Or perhaps you need to change the ROP (if such a thing is on Radeon) to ignore the colorkey. Do you see the entire video (if alpha avtive) even if another window covers a part of the video window? 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: [PATCH] radeon Xv alpha blending support
Alex Deucher wrote: does Xv even work without a colokey? Yes, at least on SiS hardware. There are 16 combinations of src and dst combination (video-ROPs) available, include the standard one (video if background = colorkey) and all possible combinations of chroma- and colorkey (which monstly aren't so useful after all). I'm not sure if they refer to source and destination, but on radeon you I guess whatever the docs call source and destination refers to source = video and destination = graphics. can adjust keycontrol based on graphics or video values and it's that part that I don't understand. there are three bit fields: one for graphics, one for video and then a mix field that sets whether you display video and graphics or video or graphics. Perhaps you can help me interpret what they do. Sure, but I am afraid I need the exact wording of the docs. I think it will be like that: If the alpha stuff is activated, the video overlay doesn't care about the colorkey anymore. Or perhaps you need to change the ROP (if such a thing is on Radeon) to ignore the colorkey. Do you see the entire video (if alpha avtive) even if another window covers a part of the video window? yes exactly! there are 3 alpha modes: key, global, and per-pixel. key uses the colorkey to display the overlay but can blend against the colorkey value. It's useful for fading in/out the desktop or the video. global mode blends the video with the graphics layer no matter what. so any windows over or under the video get blended and you can't obsure the overlay, it just blends. per pixel mode seems like the most flexible, but I can get anything useful out of it because I think it assumes you have an alpha channel in the framebuffer ( or , etc. formats). Supposedly meaning: 1) key: If video or graphics data is inside or outside a certain color range (colorkey = graphics, chromakey = video, whatever they mean by key), do something - like, as you say, blend against the colorkey. Hm, I don't see any real usefulness in this. Did you experiment with that? Is it really the colorkey the blend against? 2) Global - simplest variant: Define one global alpha value for the whole overlay, regardless of the video's or and background's color. 3) per pixel: Second your idea, assumingly this will require a 32 bit ARGB graphics background; video is being blended with the background depending on the background's alpha value. (The other way round would be somewhat impossible as video data can't contain alpha data, unless the ATI folks expect highly unusual and non-standard video data; don't think so.) 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: radeon 2d engine and alpha blending
Alex Deucher wrote: I realize that I could attempt to use it for render accel, but I was hoping to tie it into Keithp's compositing extension (http://www.freedesktop.org/Software/TranslucentWindows) to support alpha blended windows, not just hw accelerated AA text. I don't understand under what circumstances AA text is drawn using the accelerated path anyway. Openoffice uses the accelerated routines for each and every character it draws, so does x11perf if using the argument -aaXXtext (which, by the way, gets boosted from 3 to 125000/sec if acceleration is enabled - speak about usefulness). But KDE for instance never causes calls to the accelerated functions, neither for text nor for alpha blending in general (like for transparent menus, despite RENDER is selected for doing this in the KDE control center). I am riddled. I have one test application though which I got from the Rasterman Carsten Haitzler and which I used to verify the accelerated routines do what they're supposed to. Although thinking about it more, I guess the compositing manager could take advantage of the render accel to accelerate alpha blending. Well, I only develope for XFree86 (Linux kernel framebuffer stuff aside). But is that really either-or? I'm sure Keith didn't dump his RENDER extension in XServer... Transparent bitblits are supported by XAA's normal bitblit functions, how are these used? are there any apps that use them? render? Plain old ScreenToScreen copy. trans_color (the last argument to the SetupScreenToScreenCopy function) holds the (source) color which is handled to be transparent. It's as simple as that. (hint, hint: sis310_accel.c) And MD is right, it's not a plain transparent bitblit, it's colorkeyed in fact (but only using one color key, not a range). Isn't used very often, though. 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: nv driver obscurities...
Mike A. Harris wrote: I suppose that is fair enough. I'm trying to debug an annoying problem in the driver for some users having problems, and seeing hexadecimal registers everywhere instead of symbolic names is very frustrating. Mike, I really can't imagine how symbolic names would help you if you don't have hardware docs. (Well, unless one uses names like BIT_7_IS_FOR_INTERLACE_BIT_6_IS_FOR_DOUBLESCAN_BITS_5_4_ARE) For me as a developer, if I have the choice between for example SetReg(Part2Port,0x43,0x27); or SetReg(Part2Port,RTVFILCNT,0x27); I will certainly go for the first variant. Datasheets usually are sorted by register number. Using the number instead of a name saves me from 1) remembering the symbolic name I or the datasheet gave the register (Was that with '_' or without in the middle? Did I use caps?), and 2) grepping BOTH the driver AND the datasheet (or my defs.h) every time I check or debug stuff. Just my humble $.2 Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Nvidia driver relation to XFree
Tim Roberts wrote: NO, NO, NO! EnterVT/LeaveVT do NOT end up in a kernel module! The user-mode driver that is part of XFree86 does ALL of the register manipulation needed to change the video mode in and out of graphics. It's ALL done in the user-mode driver. For those drivers that DO have kernel components, the kernel sections are doing little more than DMA memory management, which cannot be done in user-mode. Register I/O and mode switching is STILL in user mode. ... Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. And where can I find that code, which interacts with the driver? I think this EnterLeaveVT functions are only a small part of this. Is the most of that card dependent stuff in there as well? It doesn't INTERACT with the driver. It IS the driver. Every driver in the XFree86 source code (which you really need to read) includes EnterVT and LeaveVT entry points, that do whatever needs to be done to switch the board into and out of graphics mode. For many of the drivers, EnterVT and LeaveVT looks the same; they just call into other functions within that driver. I think that one more thing to be said here is that the video drivers' Enter/LeaveVT are 1) completely driver private functions, and 2) - more important - not doing everything needed in order to switch to another VT or back to the server. Leave/EnterVT (with root entry points in one of the top level structures, ScrnInfo) are possibly a cascade of functions which are called one after the other in order to do this. Just - in what hacky way ever - calling a video driver's Enter/LeaveVT will have very unpleasant and unexpected results. 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: Sis DRI test
Stjepan Stamenkovic wrote: I have build X from CVS with Kernel 2.6-test8 and SiS DRI (I have a SiS 630 with 32MB) worked quite well ... like in 4.2 But there's still an out of video/agp memory Error in some applications (Serious Sam / some games with wine) but quake3 works quite well ... Well, the driver assumingly still can't swap to system RAM. Same situation as before. Set the memory to 64MB in the BIOS setup, helps perhaps a little. Also Blender and wings3d look somehow different after some time (like explained on winischhofer.net) Also at start from X I get: agp acquire failed. agpgart in the kernel? Current DRM module? 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: Sis DRI ?
Måns Rullgård wrote: Eric Anholt [EMAIL PROTECTED] writes: Is somebody currently working on the SIS DRI driver/port ? I'm new on the list and not as well informed ;) Yes, I am (though I'm nearly done with the changes I'm making to the 300-series driver unless I can get docs). It is currently usable in DRI CVS and should work from XFree86 CVS, though I haven't tested there. Is there a particular question? Which SIS chips is this about? 300 series (300/305, 540, 630, 730). Any chance we'll be seeing DRI on SIS 650? As before. 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: You suggest an upgrade, eh?
Måns Rullgård wrote: Mike A. Harris [EMAIL PROTECTED] writes: Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. I've been trying to find specs for implementing hardware RENDER support for my graphics card. I have the specs for the card. The problem is that nobody seems to know what the various RENDER functions in a driver are supposed to do, or what the structs represent. Without this information, there's not much I can do. For a start, look at the mga or the sis driver. Both accelerate aa texture blitting for aa text with quite remarkable speed improvements. 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: You suggest an upgrade, eh?
Måns Rullgård wrote: Thomas Winischhofer [EMAIL PROTECTED] writes: I've been trying to find specs for implementing hardware RENDER support for my graphics card. I have the specs for the card. The problem is that nobody seems to know what the various RENDER functions in a driver are supposed to do, or what the structs represent. Without this information, there's not much I can do. For a start, look at the mga or the sis driver. Both accelerate aa texture blitting for aa text with quite remarkable speed improvements. I was hoping not to have to wade through hundreds of lines of chip specific code and try to guess what they tell the chip to do. If I only knew exactly what the functions are supposed to do, and what the supplied data is, it would be straight-forward to have my chip do the work. The parts that do RENDER accleration are by no means hundreds lines of code. It plain two accelerator functions. I myself had no clue either when I started, and implementing this took only one day. It's basically two blitting functions: one for pure alpha map (one bitplane, only alpha values; this one is used for aa text), one for 32 bit ARGB bitmaps. If you know how to implement this on your hardware, it's really easy. You can take over most of the surrounding code from either the mga or the sis driver, and just replace the machine specific stuff. The mga driver uses the 3D engine for this (AFAIK), the sis driver the 2D engine and a small hack (for aa text, since the engine lacks support for doing source and destination alpha at the same time). If you look at the sis driver, look in sis310_accel.c for everything inside #ifdef INCL_RENDER. I am afraid that is all the help I can give you. I haven't found any documentation on this either. 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
XAA bug
In xaaPCache.c, lines 2051 and following, a Color8x8 pattern is written
to the cache.
Hm. This looks like this:
/* Write and expand horizontally. */
for (i = h, dstPtr = data, srcPtr = pPix-devPrivate.ptr; i--;
srcPtr += pPix-devKind, dstPtr += pScrn-bitsPerPixel) {
nw = w;
memcpy(dstPtr, srcPtr, w * Bpp);
while (nw != 8) {
memcpy(dstPtr + (nw * Bpp), srcPtr, nw * Bpp);
nw = 1; ^^
}
}
That should read:
/* Write and expand horizontally. */
for (i = h, dstPtr = data, srcPtr = pPix-devPrivate.ptr; i--;
srcPtr += pPix-devKind, dstPtr += pScrn-bitsPerPixel) {
nw = w;
memcpy(dstPtr, srcPtr, w * Bpp);
while (nw != 8) {
memcpy(dstPtr + (nw * Bpp), dstPtr, nw * Bpp);
nw = 1; ^^
}
}
IMHO, one can't expand the pattern from the SOURCE, but should use the
DESTINATION instead.
Everybody agree?
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: XAA bug
Mark Vojkovich wrote: Yes, it should be the dstPtr. I didn't know anyone used the Color8x8 pattern path. It's not an interesting path if you support Mono patterns. Well, months after I implemented acceleration for Color8x8 patterns I today for the first time succeeded triggering this. KDE (or Qt?) fills the background with a 2x2 pattern using this under some circumstances. I already commit the fix to the CVS. 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: Starting XFree86 without an XF86Config file
Tim Roberts wrote: On Fri, 03 Oct 2003 15:55:47 -0500, Bryan W. Headley wrote: It's 3 curves of 256 datapoints. Floating point or integer. What you have to assume is that every point on the curve is grabbable, either through a spline curve widget, or something like datapoint [123]^ red [ 45] green [ 23] blue [ 52] With the premise being, you scroll to whichever element you want with the datapoint wheel widget; the values for red/green/blue are actually what you'd call red[123], green[123] blue[123] (only because in the example above, we're at the 123rd element) This discussion needs an infusion of reality. I fully realize there are many graphics cards for which the color curves can be set exactly as you describe, as 3 arrays of 256 elements. The S3 Savages do it that way. However, the UI you describe is just silly. There is NO real-world reason to have a configuration widget that allows gamma setting on a point-by-point basis. For gamma, a single exponent (perhaps one exponent per primary) is the only thing that a UI needs to provide. Erm, brightness would be nice, too. -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org -- 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: Exporting sched_yield to the drivers
Nathan Hand wrote: Why not slice 1) send 1 megabyte ... slice 2) fifo not drained, reduce fifo to 512kB, wait ... slice 3) fifo not drained, reduce fifo to 256kB, wait ... slice 4) fifo drained, send 256kB ... slice 5) fifo drained, send 256kB Does the hardware have a register containing a pointer to the current command being executed? I solved a similar problem in the SiS driver by doing it the following way: 1) Push data into the FIFO until it's filled up to a quarter of its size 2) Before pushing further data, wait for the current command pointer to be outside the second quarter (which I am about to write to) 3) Likewise with the third and fourth quarter: Just wait until the current command pointer is outside these, and the write to this quarter without any waiting. This minimizes CPU waiting to 1/4 of the original extent. Benchmarks have shown that dividing the queue size in smaller parts than quarters makes it slower because of the more frequent polling of the command ptr. 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: [Dri-devel] XGI?
Alex Deucher wrote: Will the drivers for both current and future chips be open source? What sort of feature set will the drivers support (2D, 3D, video, multi-head, etc.)? Will databooks be available to developers? The drivers for the current chips _are_ open source 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: [Dri-devel] XGI?
Russ Dill wrote: On Mon, 2003-09-15 at 11:03, Alex Deucher wrote: Is anyone on either of these lists familiar with XGI? It seems to be a new GPU manufacturer consisting of a merger of Trident and the SiS graphics division. here's their website: http://www.xgitech.com/index.htm They have some interesting products products (dual GPU solution). Some of their other stuff looks similar to existing SiS and trident products. They mention linux support, but I see no links to drivers anywhere. does anyone know anymore about this company? Are they writing xfree drivers or with any existing drivers work with these chips? SiS has has a bad record of giving out specs on it's newer chips; trident I guess has been a little bit better. I guess this company will do it like SiS did in the past: Make the chips, but leave the integration into boards to other manufacturers. (The embedded-and-customized-hell will never end...) My bet would be that ECS and MSI will be among the first to design boards for these chips. SiS spins off their 3D buisness and it gets named Xabre Trident buys/merges, whatever with Xabre, and the new company is named XGI I think they it became official on the 13 or 14th, don't remember. So for now, its just the Xabre products and the trident products (cyberblade2, etc). The Volari's specs look indeed like the Xabre's, except for that Cipher video processor and the dual-GPU option. Apart from this (and 3D, of course), these chips should be well supported by the current SiS driver (well, as soon as I get the PCI IDs) 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: MergedFB and XINERAMA
Billy Biggs wrote: As a more specific version of my last post, do MergedFB drivers not support the XINERAMA client extension such that applications can know that there are multiple heads? Only the SiS driver. A patch for radeon (by alex deucher) is in bugzilla. mga does not support that yet. I would hope that these two things are not mutually exclusive. Well, Xinerama and MergedFB don't go too well together. I have a section on the problems involved on my website (URL in sig). Search for Xinerama. 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: Dual-head without XINERAMA ?
Billy Biggs wrote: http://vektor.ca/bugs/atidriver/xpdy2.log includes the lines screen #0: dimensions:2560x1024 pixels (867x347 millimeters) resolution:75x75 dots per inch is that any use ? Not in general. I use the vidmode extension to get the current resolution, since my users often make 720x480 modelines and such things and switch to that (using ctrl-alt-+) to play video. However, I use the geometry information to calculate the pixel aspect ratio to use. Erm, I might be mistaken, but the geometry information has nothing to do with the current display mode. If I have a screen of 1024x768, 260x195mm according to xdpyinfo, I still receive the same values after switching, say, to 1280x768 (which has a totally different aspect ratio)... hence, geometry is static and obviously independent of the current display mode... So in this case, vidmode tells me our resolution is 1280x1024, and X tells me that we're not using XINERAMA and that our geometry is 867x347 millimeters. Makes sense? Not really. That xdpyinfo output is strange - 2560x1024 looks like two screens of 1280x1024 aside each other; is this a radeon machine using Alex' driver? Seems it's not the current one as it reports that Xinerama is not supported. 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: Dual-head without XINERAMA ?
Alex Deucher wrote: It appears that the ati firegl driver does not support xinerama when using its dualhead/mergedfb mode. I'd be happy to add xinerama support for ati's driver. just tell them to release the source ;) Hm, I don't recall any required explicit code for Xinerama support in my driver.. (speaking of normal dual head, not MergedFB) The Xinerama extension is initialized after the driver has done its part(s). If the option Xinerama is set, it's being added to the list of extensions, if not - not. Xinerama is fully transparent for the driver... No idea what the ATI folks have done there... seems to be some sort of mergedfb mode, too. Does that piece support normal dual head mode (speak: 2 device sections, 2 screen sections, etc)? 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: Dual-head without XINERAMA ?
Billy Biggs wrote: Thomas Winischhofer ([EMAIL PROTECTED]): No idea what the ATI folks have done there... seems to be some sort of mergedfb mode, too. Does that piece support normal dual head mode (speak: 2 device sections, 2 screen sections, etc)? Yes it does, but users always whine and complain when I tell them to use it. Frankly, I understand that - mergedfb is way better :) 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: i855 and 1400x1050
Alessandro Temil wrote: Egbert Eich wrote: David Here you are, i attached both i810 and vesa driver XFree86.0.log. (by the way, i'm new of this mailing list, if it doesn't allow messages with attachments i'll repost them inlined asap.) This moring i wrote to intel asking for the specifications, i hope to get a reply soon. Neither the VESA nor the i8xx driver lists any 1400x1050 mode. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel I know, that's why we need to program directly the video chip, as the windows driver does. Seems so. I found no trace of a 1400x1050 mode in the BIOS. However, it seems to support different panel types (brands, models) of that very resolution. If the reason for not implementing a mode for the native resolution in the BIOS is that the chip can be connected to many different video bridges, this is simply dumb. That way they need a huge windows driver, taking care of all that, which furthermore needs to be updated permanently if a new machine comes out... SiS folks haven't updated their Windows driver since February, and it works with about every machine in existance (due to the BIOS of all machines containing info on all supported modes for their host machine) A register dump from a windows driver would be the only way, 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: i855 and 1400x1050
Alessandro Temil wrote: David Dawes wrote: On Fri, Sep 05, 2003 at 11:25:35AM -0700, Tim Roberts wrote: On Fri, 05 Sep 2003 20:04:19 +0200, Alessandro Temil wrote: Christian Zietz wrote: The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. It is possible that the BIOS actually knows the mode, but has no VESA number for it. I have seen this at least on SiS hardware: SiS BIOSes maintain two mode number lists, one with internal mode numbers, one for VESA mode numbers. As the i810 BIOS, it has no VESA number for 1400x1050. A closer look at the BIOS would perhaps help... if it turns out the BIOS has in internal mode number, one could change the mode switching from VESA to (direct) int10 and use the internal mode number(s). 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: i855 and 1400x1050
Alessandro Temil wrote: Thomas Winischhofer wrote: Alessandro Temil wrote: David Dawes wrote: On Fri, Sep 05, 2003 at 11:25:35AM -0700, Tim Roberts wrote: On Fri, 05 Sep 2003 20:04:19 +0200, Alessandro Temil wrote: Christian Zietz wrote: The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. It is possible that the BIOS actually knows the mode, but has no VESA number for it. I have seen this at least on SiS hardware: SiS BIOSes maintain two mode number lists, one with internal mode numbers, one for VESA mode numbers. As the i810 BIOS, it has no VESA number for 1400x1050. A closer look at the BIOS would perhaps help... if it turns out the BIOS has in internal mode number, one could change the mode switching from VESA to (direct) int10 and use the internal mode number(s). Thomas I'm not sure to have the necessary knowledge, but may give a try, do you know any good bios dumper/disassembler that runs under linux that you would suggest for this task? Send the BIOS to me (privately), I'll have a look. To dump it, do dd if=/dev/mem of=/tmp/vidbios.bin bs=1 count=65535 skip=786432 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: RENDER question
Michel Dnzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Why the h*ck is render so fast on your machine? One possibility is that doing it unaccelerated requires the CPU to read from video RAM, which is terribly slow on my shared-memory architecture machine. dga (by pressing b) reports about 500MB/sec for writing, and only 37MB/sec for reading. Perhaps the 2D engine suffers from the same bottle-neck when doing the alpha blending... (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? I hadn't even set this until this morning. (In my tests, source alpha was never used as logging the calls showed). They are called under 4.2, but not under 4.3. Does the server make the difference, or the libraries? Have you traced the X server which would call them? Qt (current debian version) never uses them, be it under 4.2 or 4.3. (One SuSE user reported they do on his system, though). OpenOffice (current Debian version) uses them under both 4.2 and 4.3. Perhaps they have their own routines? Frankly, I think it's only related to my inconsistent setup (Debian SID, 4.3 binaries from XFree.org copied over the 4.2 setup). I wouldn't bother too much about this. Maybe freetype (which I use the Debian sid version of) needs to be recompiled for 4.3. I don't think freetype is directly related to this, do you mean Xft? Well, I confess, I am not an expert on these hundreds of libraries involved with text rendering :) 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, and multiple heads: thoughts and ideas
Alex Deucher wrote: Next, mergedfb... I've been thinking about creating generic xfree support functions to replace the chipset specific ones for mergedfb. This would make it easier to add mergedfb to other chipsets that support dualhead. Where should this live? also, as far as pseudo-xinerama, should that be made part of the generic mergedfb code or part of xinerama proper? i.e., to extend xinerama to handle both multi-card and single card xinerama. Or is all of this going to be refactored in xfree 5? IMHO, pseudo-Xinerama as we have it today is far from being perfect, partly because MergedFB mode does not fit into the Xinerama idea of two fixed-sized screens (RandR ignored here) with a fixed boundary between them. I'd prefer extending Xinerama for MergedFB specifics instead, and removing that pseudo-stuff in the long term. However, this would require some enhancements for the Xinerama extension (signals to clients, etc). That is, if at all, XF5 material, 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: RENDER question
Soeren Sandmann wrote: FWIW, I get numbers comparable to Thomas' with an Nvidia Geforce 2, a 1GHz CPU, and a stock Red Hat 9 server using the free driver: 96000 reps @ 0.0628 msec ( 15900.0/sec): Char in 30-char aa line (Charter 24) Well, now I feel good again with my 105000/sec here :) Thanks Søren and Aidan. 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: RENDER question
Mark Vojkovich wrote: On Thu, 28 Aug 2003, Thomas Winischhofer wrote: Michel Dänzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Yours is unusually fast. You must have AGP fastwrites on. What value are you referring to? 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: RENDER question
Carsten Haitzler (The Rasterman) wrote: please please please PLEASE! accelerate everythig you can :) http://www.rasterman.com/files/render_bench.tar.gz Is it correct to assume, that the image I see over a rainbow-like background is the result of RENDER, and over a grey-shaded background from imlib? If so, it looks good for RENDER accel for the SiS driver... (erm, well, unscaled yet) 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
RENDER question
Since I recently found out that SiS hardware _does_ support per-pixel alpha-blended bitblits, I could finish the (yet disabled) render acceleration. The only problem I encountered: The functions that I provide (SetupFor/SubsequentCPUToScreen[Alpha]Texture) are never called as it seems How come? Shouldn't AA text be drawn using these functions? Is there any test program for 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: RENDER question
Sorry for replying to my own post: Since I have found only one application triggering calls to the accelerated RENDER functions (openoffice), I wonder under what circumstances these functions are called as regards anti-aliased text? Why isn't for example Qt (which I use in version 3.1.1 here) or Mozilla (1.4, Debian's xft-enabled version) triggering these functions? Thomas Winischhofer wrote: Since I recently found out that SiS hardware _does_ support per-pixel alpha-blended bitblits, I could finish the (yet disabled) render acceleration. The only problem I encountered: The functions that I provide (SetupFor/SubsequentCPUToScreen[Alpha]Texture) are never called as it seems How come? Shouldn't AA text be drawn using these functions? Is there any test program for this? -- 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: DPI with multiple heads and virtual desktops
Alex Deucher wrote:
How is DPI supposed to work if you have a virtual desktop larger than
the current mode? the current code seems to produce the wrong DPI.
xf86SetDpi() has the following code:
if (pScrn-widthmm 0) {
pScrn-xDpi =
(int)((double)pScrn-virtualX * MMPERINCH / pScrn-widthmm);
}
if (pScrn-heightmm 0) {
pScrn-yDpi =
(int)((double)pScrn-virtualY * MMPERINCH / pScrn-heightmm);
}
if you have, for example,
DisplaySize 300 230
and a virtual resolution of say 2048x768 and a mode of 1024x768, the
DPI would get set to 173, 84. which (I think) is wrong. it should be
86, 84 which is what you would get when your mode matches your virtual
resolution. I'm having the same problem with Mergedfb since it uses a
virtual resolution with two viewports looking into it. I could add the
heightmm or widthmm of both heads to make the DPI correct for the
virtual size with respect to the two heads. I'm not sure how xinerama
deals with it. maybe the current behavior is right? I dunno.
Thoughts?
Without actually having looked at this, my preliminary opinion is that
what we do presently is correct. I don't see the mode dimensions
anywhere in the calculation you quoted above.
virtualX and Y can be bigger than the viewport in any case (not just
MergedFB mode). I think the whole DPI system is based on the assumption
that you _see_ the whole (virtual) desktop, ie you're running at the
maximum mode(s on each head). The only thing one has to do is to set
DisplaySize correctly, namely to the over-all size of BOTH heads
(depending on their relative location, of course).
As Aitchison showed in his reply, Xinerama does basically the same as it
just resizes the mmWidth/Height with regard to the second head, although
it does this by calculating some sort of average.
Be it adding the second head's dimension to the mmHeight/Width, be it
calculating an average, both methods are likewise inaccurate if you use
two output devices with different actual DPI values.
But as said, this is my unqualified opinion without looking at it
closer. I'll think about 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: Xrender transforms...
Alan Hourihane wrote: On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, It's disabled because it doesn't work as Render. SiS hardware only supports one alpha per operation (and not per pixel). I kept the code within #if 0s for possibly upcoming XAA transparency support. 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
cmap symbols
Is there any good reason for not putting the other xf86... functions for the cmap stuff into the lookup table in xf86sym.c ? Specifically, what about the gamma functions in xf86cmap.c? 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: Seeking MergedFB - Xinerama development advice
Sorry for replying to my own post: Alex, I just uploaded a new version (to my website), this time with RandR support for the Pseudo-Xinerama stuff. This required quite a few changes, such as - recalculating the maxCRTx_xx fields in UpdateXineramaScreenInfo() rather than doing this once during mode-linking; but only if the virtual size has changed; - calling UpdateXineramaScreenInfo() in SwitchMode() etc. Unfortunately, KDM does not support RandR as it seems, so I have not tested this in reality yet. Thomas Thomas Winischhofer wrote: Alex Deucher wrote: I'd be interested in seeing your code once you have decided on a route, so that I can update the radeon mergedfb driver. Alex, the code is now available on my website (URL in sig). Look for everything surrounded by #ifdef SISXINERAMA, and check the additions to the CopyModeNLink() function (setup of maxCRTx_xx). I wrote a little description which can be found in the options chapter about MergedFB mode on the mentioned website. Please read that first. When reading and trying to understand the code (which is far from being as trivial as I wrote in the original message of this thread), think of the following special situations: - overlapping viewports (virtual desktop too small for largest Metamode), - Virtual desktops larger than the largest Metamode - Clone modes whereas the CRT2Position is not Clone The SiS-Pseudo-Xinerama extension will be disabled if the user selected Clone as the CRT2Position (whatever you call this in the radeon driver), and if only clone modes are given (that is, if the metamodes list only contains modes without a - and a second mode following). For a while I thought of updating the Xineramainfo with each mode switch, since the boundary between the two heads eventually changes with every such event. But after having implemented this, I turned out that, at least with KDE/KDM, that had no effect; seems that the KDE system queries the Xinerama extension only once, at startup... So I went for a static information, calculated based on all Metamodes given, trying to find a somewhat usable common. Essentially, the Xineramainfo for each (pseudo-)screen is the maximum scrolling area of each head, taken from all Metamodes given. So far, this is the smartest solution I could come up with. KDM works well with this, even with overlapping pseudo-screens, as does Xine and some other applications. I don't know about other window managers, though. Some Metamode-combinations are, of course, very inconvenient for my current concept, such as the 1280x1024-1024x768 1024x768-1280x1024 example I already mentioned. But I think, manually disabling Xinerama support in such cases this is the price one must pay... Comments appreciated, especially from folks using the NVidia binary driver with its Xinerama support. 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
Seeking MergedFB - Xinerama development advice
I now implemented a small Xinerama extension for the SiS driver's MergedFB mode, following the binary NVIDIA driver's example. However, since Xinerama and MergedFB (or Twinview, if you want) is not entirely the same, I encountered a logical problem during programming: With Xinerama, the two screens never change size (unless you use RandR, this theoretical possibility is left aside in the following), nor position during server life-time. Hence, filling in the PanoramiXData structure is trivial and only needs to be done once at server startup. MergedFB mode is different in this regard: Here, there is only one screen visible for the server and the clients, and heads' viewports can float around more or less freely in the virtual framebuffer. There are no 2 screens in the true meaning of that word; the screens (which should be given information about by querying the Xinerama extension) in MergedFB/Twinview are determined by the very metamode used. Imagine the following example: Virtual framebuffer 2304x1024, meta modes 1280x1024-1024x768 and 1024x768-1280x1024 (meaning: Mode 1 is 1280x1024 on head 1, 1024x768 on head 2; Mode 2 is 1024x768 on head 1 and 1280x1024 on head 2). Mode 1: (fixed width font required for viewing) +--+ |++ +-+| ||| | || ||| | || ||| | head 2 || ||| |1024x768 || || head 1| | || ||1280x1024 | | || ||| +-+| |||| ||| Virtual framebuffer| |++| +--+ Mode 2: +--+ |+-+ ++| || | ||| || | ||| || head 1 | ||| ||1024x768 | | head 2 || || | | 1280x1024 || || | ||| |+-+ ||| |||| |||| |++| +--+ (For those not familiar with MergedFB mode: The smaller head in this szenario can be scrolled freely within its boundaries, ie there is never an area of the framebuffer which is not reachable.) As you can see, the boundary line between the two heads differs depending on the current metamode: At Mode 1, it is at 1280, at Mode 2 at 1024. Now for the problem: At least KDM (which I used for testing) queries the Xinerama extension only once, during startup. What values should the XineramaQueryScreens() function return? Preliminarily, I went for the following solution: If head 2 is right of head 1, (other positions not regarded in this example) screen 0 (head 1) x = 0 y = 0 width = maximum X of all modes for this head height = virtual Y framebuffer size screen 1 (head 2) x = virtual X fb size - maximum X of all modes for this head y = 0 width = maximum X of all modes for this head height = virtual Y framebuffer size In numbers: screen 0 (head 1) x = 0 y = 0 width = 1280 height = 1024 screen 1 (head 2) x = 1024 y = 0 width = 1280 height = 1024 This gives two overlapping screens... The result is: If running in Mode 1, a smart application might place a window meant for head 2 at (1024, 0) - which is partly in head 1's viewport, and partly outside head 2's viewport. However, the window is correctly placed at these coordinates if currently running in Mode 2. Does anybody have a better solution? Should I perhaps use the current viewport positions/sizes for this, and update the structure on each mode switch? (At least with KDM, this won't have any effect as it seems to query the Xinerama data only once, as said) Especially for Mark V.: How is the binary NVidia driver doing this? Any advice appreciated. 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: Seeking MergedFB - Xinerama development advice
Alex Deucher wrote: I'd be interested in seeing your code once you have decided on a route, so that I can update the radeon mergedfb driver. I already thought of you. You will, no worries. 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: tvout in XFree86 drivers
The SiS driver fully supports TV out. Open source. Thomas Alex Deucher wrote: several drivers support TV out but not all. I believe via, trident, and savage have open source support for most tv out options. Matrox provides binary support for the g400 (although you can get tv out working with the linux frambuffer driver for all recent matrox cards), as does nvidia. for ATI there are several open source utilites out there as well as GATOS, but they all are coded by trial and error since ati hasn't released tv out specs as far as I know. I'm not sure abotu ATI's binary drivers. was there a particular chip you were interested in? Alex --- Andriy Rysin [EMAIL PROTECTED] wrote: Can anybody tell me what's the status of tvout support in XFree86 drivers? As far as I understand it's only available for several graphic cards and only from their manufacturer close-source drivers. From gatos project I learned there are some legal issues with ATI boards but don't know anything about the others. Thanks, Andriy __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ 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: Dell C400 fix applied to 855GM?
Egbert Eich wrote: Sottek, Matthew J writes: The Windows driver does full mode programming including all the external digital components from many 3rd party companies. The open source XFree This is pretty much what the SiS driver does after Thomas got his hands on it. It programms the SiS and it knows about several video bridges attached to it. OT, but for the record: With SiS, it is actuall the other way round. SiS' Windows drivers do mode changes _exclusively_ by calling the BIOS. That's why they never need to update their Windows driver... and produce zillions of different BIOSes instead :( 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: SiS news
Alex Deucher wrote: I just saw this on extremetech today: http://www.extremetech.com/article2/0,3973,1101038,00.asp Looks like SiS is spinning off it's graphics chip division. perhaps this could mean better access to databooks! We'll see. I'd better be not too optimistic, since SiS intends to hold 99,99 % of the shares of this company. I think it won't get any better. Basically it will be the same folks ruling there... 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: Reading a file. works for me !
David Dawes wrote: The sis driver goes one better and allows you to tell it which file to to overwrite :-( This has no real function other than debugging. It's to make it easy for people to send me their video BIOS images. Can be removed any time. On second thought, I will remove this *now*. There are plenty of other ways to do the same thing anyway. 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: Reading a file. works for me !
David Dawes wrote: On Thu, Jun 26, 2003 at 06:46:15PM +0200, Thomas Winischhofer wrote: David Dawes wrote: The sis driver goes one better and allows you to tell it which file to to overwrite :-( This has no real function other than debugging. It's to make it easy for people to send me their video BIOS images. Can be removed any time. Looking at it more closely, the mga case seems much worse. The sis driver only writes to a file name specified in the XF86Config file, and only root should be able to specify that. I just removed 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: status of SiS 3d?
Alex Deucher wrote: right now just the 300 series (300, 305?, 540, 630/S/ST, 730) have DRI support. the old series 6326, 620, 530 don't have DRI support, but but there are docs available (on the dri website I think) to write a DRI driver; there was also a utah-glx driver for the that series. I think the 6327 might have been the internal sis name for the 300 series, although that's just a guess on my part. The 6326 and the 300 series might be simialr enough to support them both with one driver, but I No, they are not. don't know. Thomas Winischhofer would probably be a better person to ask. I was thinking of tackling this myself to try and learn more Erm, no. I know nothing about DRI. Please don't encourage people to ask me about it :) about the DRI, and I'd be willing to try to help you if you wanted to. I'll even provide cards. sis 300 series cards are also very cheap. I wouldn't buy a 300 series card nowadays, as cheap as they might be. They are quite slow and far behind today's standards. Their only strong side is video support. What I'd like to know is how different the 3D engine is on the 315 series is from the 300 series, and whether that could be supported at some point. It's totally different; both register layout and other internals have changed - not even speaking of the Xabre 3D core (which is totally different to the 315's again) It's doubtful however since sis refuses to hand out docs any more. Once they are through with what is going on right now (can't tell you), the situation might become better. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net mailto:[EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another RENDER question
Keith Packard wrote: Around 0 o'clock on Feb 28, Thomas Winischhofer wrote: The hardware I am dealing with does not support ARGB textures (at least not in 2D level, and I don't want to mess with DRI), but alpha blended bit blits. Using the '3D' hardware needn't entail dealing with DRI. The MGA driver does precisely that for Render acceleration. Alright. That should be possible. Can anyone explain to me what exactly (in the words of common 3D language) the mga driver does? The register setup is totally uncommented in the driver code. I went through my docs for the 3D registers for the hardware I am dealing with (SiS 300 series) and I saw no sort of command for just applying a texture mapping or anything similar. I can only define vertices for drawing primitives like triangle, line and point - which is rather complicated, partly because all coordinates are in floating point format. Furtherly, I can define textures (and Z buffers and alpha settings and a lot of other stuff). But it seems the texture mapping is done based on the results of the setup engine (which does the drawing primitives) in the transformation phase. I saw no command for doing a simple transformation without firing the setup engine (ie issueing a drawing primitive) before. Sorry if that sounds rookie-like - fact is I am a rookie on the area of 3D programming. Is there any 3D expert around who could give me a hint? Docs can be provided on request. The difference being: While ARGB textures contain an alpha value for each pixel, the alpha blended bit blits render with a static alpha value for all of the bitmap data. It might be of some use; applications can specify this operation through Render with a single-pixel tiled 'mask' operand to composite, but it won't speed up text or geometric operations at all. As Mark pointed out I will save the code I already wrote for features like translucent windows. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Another RENDER question
The hardware I am dealing with does not support ARGB textures (at least not in 2D level, and I don't want to mess with DRI), but alpha blended bit blits. The difference being: While ARGB textures contain an alpha value for each pixel, the alpha blended bit blits render with a static alpha value for all of the bitmap data. Is this hardware capability of any use, be it RENDER or any other XAA function? Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.2.99.902 (4.3.0 RC2) tagged
David Dawes wrote: Have we achieved code freeze? Are there major outstanding issues that are holding us up for the tag date of 27 Feb 2003? There's nothing standing in the way of it at the moment. May I suggest that you (the maintainer, that is) update the PCI ID's once again before a code freeze? The file in use is 4 months old and I added the ID's for the last generation SiS chips one month ago. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Centralize XXXCopyMungedData
Egbert Eich wrote: Just my $0.02: Watch out when centralizing the memory allocation routines, different hardware (ie drivers) use different granularities. Yes. Any functions provided by the core server will have the status of helper functions. Therefore it they don't meet your needs you can replace them with your own. Erm, I know that... :) What I actually meant was if Björn starts patching *drivers* (and that's what his statements sounded like) he'd better take care. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
David Dawes wrote: Instead of Support (accelerated) for the SiS 530, 620, 6326 is provided by the sis driver. The 630, 300, and 540 are also supported, but this code is new and there are some problems with it in this version. it should say Support (accelerated) for the SiS 6326, 530, 620, 300, 540, 630, 730, 315, 550, 650, 740 is provided by the sis driver. The Xabre (SiS 330) might be supported by this is completely untested. Thanks. I've made those changes. ARGH... just saw that: Please add 5597/5598 to this list, and remove it from the summary line. Sorry, I really lost track :) So, for copy-paste convenience: -- 4.3.0: Support (accelerated) for the SiS 5597/5598, 6326, 530, 620, 300, 540, 630, 730, 315, 550, 650, M650, 651 and 740 is provided by the sis driver. The Xabre (SiS 330) might be supported by this is completely untested. Summary: Support for the 86C201, 86C202, 86C205, 86C215 and 86C225 is currently only available in 3.3.6. Support for some newer chipsets is only available in 4.3.0. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Centralize XXXCopyMungedData
Björn Augustsson wrote: I agree with you that this code doesn't have to be replicated by each driver. There is a lot more code in the video drivers which could be cept in a centralized place. I certainly agree. Gotta start somewhere though... Just my $0.02: Watch out when centralizing the memory allocation routines, different hardware (ie drivers) use different granularities. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ARGB cursor testing
I am about to implement ARGB hardware cursor support into the sis driver. However, since I am not running CVS (because this is a production machine, too) I need a test bitmap of a 32x32 cursor in ARGB format, just like it is provided in the pCurs-bits-argb field to the LoadCursorARGB function. The image should not be larger than 32x32 because the SiS hardware can only handle cursors up to this size. Can anyone provide me with the C source of such an image (and a description what it should look like)? Thanks, Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
