Re: [Xpert]Trio 64 3D
Oops, the hanging issue was caused by a mouse not being openable. However, the problems persist. I'm now getting the same part of the desktop multiple times on my screen (tiled vertically) and depending on which mode green vertical lines (which, as would be expected do no corrupt the hardware cursor but do corrupt the cursor drawn in software). Anybody got any suggestions or modes known to work with this specific card? -- Frank v Waveren Fingerprint: 21A7 C7F3 fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 1FF3 47FF 545C CB53 Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X Windows System problem for RedHat 8.0 on IBM ThinkpadR32 on Windows-hosted vmware
On Sun, 27 Oct 2002, Kuang-Ching Wang wrote: I am installing redhat 8.0 on my IBM thinkpad laptop R32. XFree86 fails to start after installatoin complaining about No screens found. Is it something specific to the way I configure my laptop LCD display, or is it about VMware?. Below I attach the XF86Config contents and the crash log. When running under Windows-hosted vmware, use the vmware driver not the radeon driver. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]private mailing lists - an archive or read only access?
On Sun, Nov 03, 2002 at 10:43:53AM +, Dr Andrew C Aitchison wrote: [...] I have to admit that I feel different about the xpert and devel lists. Xpert has a lot more traffic, and lots of traffic that, while it needs an export to answer it, doesn't really interest an expert. Devel has thus become a list that I read in a different from a of mind from xpert. [...] Otherwise I'd suggest splitting devel into a closed list for things that had to kept confidential, and a moderated, archived public list. After all the posts here before about the status and roles of the xpert and private lists the only certain thing is that there is no certainty! As said before I would like to be able to follow the XFree86 development closely - wherever that is... So I would like to see the idea of spliting the devel to come true not only because I don't foresee my XFree86 membership application being processed within my lifetime, but also because I think that open source development should be _open_ too. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]private mailing lists - an archive or read only access?
AA On checking, it appears that, apart from the lists for submitted patches, AA all the private lists are defunct except for one, the devel list. Or are there actual resons why outsiders can't read these lists? (copyright stuff and what not?) AA Officially, that is the only reason why the devel list still exists, AA but devel does still have a lot of traffic that could perfectly well AA be made public. With a few exceptions, though, nowadays most of the interesting traffic is on xpert. The private devel list is mostly used for urgent internal announcements (e.g. announcements of feature freezes), interesting information that we don't want to see on slashdot (``I met B. G. III in the lift and he told me that XFree86 sucks'') and, very rarely, internal disagreements. You are really not loosing much. But we do feel more comfortable with an internal list. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]VNC and freetype - please Help!
I don't know if the VNC X server supports TrueType fonts. If not, you could run an XFree86 font server and point your VNC X server at it. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Questions about TinyX (simultaneous monochrome color screen xserver)
MN 1. Can TinyX use monochrome buffer ( depth=1) in Linux even though the MN folder of mfb is not used? Yes. fb can deal with 1bpp framebuffers. MN 2. If the answer to above question is YES, what are steps to create it in MN Linux? Both Xvesa and Xfbdev will take depth one modes into account. The relevant code is in vesa.c:vesaScreenInitialize and fbdev.c:fbdevScreenInitialize respectively where fb[].visuals includes 1StaticGray and fb[].depth gets initialised to 1. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]private mailing lists - an archive or read only access?
José Fonseca: As said before I would like to be able to follow the XFree86 development closely - wherever that is... So I would like to see the idea of spliting the devel to come true not only because I don't foresee my XFree86 membership application being processed within my lifetime, but also because I think that open source development should be _open_ too. Politically I agree with you. Personally I value being in a private club, but I wouldn't claim that the benefits to XFree86 (a bunch of developers with massaged egos is the only one I can think of) outweigh the costs (a bunch of developers with bruised egos). On 3 Nov 2002, Juliusz Chroboczek wrote: You are really not loosing much. But we do feel more comfortable with an internal list. Is it still possible to get onto the internal list, or has membership become fossilised because everything happens on the xpert list ? While we have discussions on devel that could be on xpert, we need a way for people like Jose to get onto the internal list. I'm not really sure about making devel public; how are people supposed to decide between newbie, xpert and devel ? I think the original idea was that the please help me stuff would be on newbie (although that name doesn't give the right impression) and xpert would only have discussion of future developments. By not reading newbie I guess I've messed that up, but if we made devel public I'd be afraid of another round of mailing list inflation (ie the xpert traffic moving to devel, only the people who read newbie reading xpert, and newbie stuff all moving to xpert :-). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Intel 845 with XFree86 4.2.99.2 doesn't work
I had founded my error. For some reason, the file xinitrc is not copied to the library directory. That file has the startup windows information (there are 3 or 4 xterm windows and a console and a clock). I copied and XFree86 is running in my system. In the logs files is a message about V_BIOS or something like that. I don't know what means that. thanks and I sorry for this false alarm. __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Intel 845G onboard video on FreeBSD 4.7
Constantine I saw two options: 1.- Install XFree86 but select a vesa driver. In /install/sysinstall you have to select text mode setup to be able to select the vesa driver and the rest of the drivers and resolution. Cons: Maybe the resolution is not very good. Take a look at VideoRam parameter. Pro: Is the best option in the short time to be able to get XFree86 working right now. 2.- Install XFree86 from cvs. That carry out version 2.4.99.2 and is working like a charm. make World make install Cons: You will need to create a Makefile (include ports.mk, or something like that) to register that application in FreeBSD. Because the installation process is generic and doesn't include the procedure to create the entry in /var/db/pkg for registration process. If you give the command pkg_info you will find that XFree86 is not registered. And if another program need it, you will receive a message about a requiered program is not installed. Right now I'm working in the process to create this file. I'm using FreeBSD 4.7 too. 3.- Wait for the release of XFree86 4.3 I don't know the estimated release date. bye __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]private mailing lists - an archive or read only access?
AA I think the original idea was that the please help me stuff would AA be on newbie (although that name doesn't give the right impression) I fully agree. I would expect many people to feel offended at being forced to write to a list with such a name -- let him who's never been childish cast them the first stone. AA By not reading newbie I guess I've messed that up, but if we made devel AA public I'd be afraid of another round of mailing list inflation Let's face it -- it already takes A$1.8 to get a green note. I think it may be a good idea to move user support to ``xpert'', make ``devel'' public and move XFree86 development to it, and create a new ``private'' list for internal announcements only. Naming the new list ``private'' would have the additional advantage of reminding people what it is for. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Son, 2002-11-03 at 06:17, Elladan wrote: On Fri, Nov 01, 2002 at 02:30:29PM -0800, [EMAIL PROTECTED] wrote: Sender: [EMAIL PROTECTED] On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? I've just chatted with Keith Packard on this. This interface (an ioctl that blocks) isn't a good one. How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) It might be best to provide both interfaces. It's probably not significantly harder to provide both API's - they both trigger off the same hardware event. Yes, I'm looking into adding a flag to the ioctl so it sends a signal instead of blocking. Shouln't be too hard, but I haven't found out yet whether a signal can be delivered from an interrupt top half, if anyone knows I'd appreciate letting me know before I find out the hard way. :) Oh, and are there any opinions about the signal to use, SIGALRM or something else? Some things to consider: Very nice: * The interface needs to provide a vblank counter, so the user can easily detect dropped vblanks. Has been there from day 1. I wonder what to do about this for the signal though, put the sequence number into the siginfo (is that possible?), or is the information you get back from the ioctl enough? The ioctl also provides a timestamp, but that's pretty arcane yet, so people who intend to use that please look at it and help improve it if necessary (hint, hint, Billy Biggs :). * It would be nice to provide a way to get either the start of the vertical blanking period, or end end of it (or both). The start is most important, of course. Only the start is supported so far. Nice but not as important: * It would be nice if the interface provided a way to request the current scan line, and block on particular scan lines. Hardware which didn't support this (eg., LCD monitors, less-good video cards, etc.) would of course be expected to return an error. What would that be useful for? As you've explained very well in your other post, the various latencies don't allow for such fine grained timing. * It would be nice if the interface provided a way to latch particular simple actions, such as a buffer flip, to the interrupt directly. For example, with an ioctl: vbc.action = VB_SWAP_BUFFERS; vbc.arg1 = BUFFER1_TOKEN; vbc.arg2 = BUFFER2_TOKEN; ioctl(vblankdev, WAIT_FOR_VBLANK_AND_DO_SOMETHING, vbc); Here, the ioctl blocks until the vblank, and the driver performs the command in the interrupt handler if possible. Not sure about this. I've played with doing this for flips in the radeon 3D driver, and it didn't work out all that well. Granted, I didn't do the flip in the interrupt top half, but I'm not sure if that's feasible. Remember, what people need isn't *only* a way to avoid tearing by syncing on the vblank. They also need a way to schedule output onto the vblank intelligently. For example, a video player needs some way of determining what the refresh rate is, so it can select a scheduling strategy for its output. I think that should be possible with what we have? IIRC all the drivers that support this ioctl also support XVideo double buffering synced to vertical refresh, so if you do the XvPutImage immediately after you get notified about a vertical blank, you can be pretty sure it'll be displayed on the next one. And you can deduce the refresh rate from the timestamps. PS: A: No. Q: Should I include quotations after my reply? ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]No DRI for Dual-headed setup?
[ First off, it's better to post to a DRI list about the DRI ] On Son, 2002-11-03 at 06:06, Kacper Wysocki wrote: I've finally gotten what I want (within XF86's limitations) for my X, namely -radeon accel working(windows are still horribly sluggish-try it and see: grab a window by its bar and shake it. Repeat on well-configured(yeah right) winblows with same gfx card. You see what I mean?) Fortunately, I can't do that comparison here, but it's pretty fast, even with a window that covers the whole screen. Does the lack of perfect smoothness bother you? Note that the window manager can make a huge difference there, e.g. sawfish was much worse than metacity here. -dual headed, no xinerama (better than bug-eyed xinerama) -xv working -dri working (Only in 16bit, one-headed and while root) All this by building from CVS, with the help of one Andrew Atrens(thanks!) But of course I'm not satisfied with this: (WW) RADEON(0): Direct Rendering Disabled -- Dual-head configuration is not working with DRI at present. Please use only one Device/Screen section in your XFConfig file. [...] Now my question is: if there's a problem in Xinerama, and I don't run xinerama, can I safely enable this? If it was that simple, it wouldn't have been disabled in the first place... Or does dual-head configuration include dualheaded setups that don't run xinerama? It does say 'dualhead', not 'Xinerama', for a reason. The 3D driver has absolutely no notion of a shared entity yet. What should work would be implementing dualhead with a single framebuffer on top of the CloneDisplay support in current CVS. Why is drm access restricted to root, and how do I go about changing it? Simple /dev/dri permissions issue here(I modified this, but can't check it right now)? Probably, see http://www.xfree86.org/current/DRI6.html#10 And what gives with the 16bit(and 32bit, haven't checked) only support? Radeons can only render 3D primitives in depth 16 and depth 24, fbbpp 32. Depending on the desktop resolution and the available video RAM, the DRI may only be enabled in depth 16. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Older S3 chipsets (was: Re: [Xpert]Driver work for S3 864 chipsets)
Tothwolf wrote: On Mon, 28 Oct 2002, Jonas Nickel wrote: I would like to know if there is anyone currently working on porting the driver for S3 864 chipsets to the XFree 4.x tree. I have some older machines with S3 adaptors and would like to start using XFree 4.x instead of XFree 3.x on them. In case there isn't anyone working on the drivers I would like to know if there is any interest in these drivers as I would then try to spare some time and start the work on these. AFAIK, no one is working on support for the older S3 chipsets right now. I have a number of S3 968 based boards with an IBM 526 RAMDAC that I would like to get working too. I have so far been unable to obtain any programming information for the chips on my boards, although my current workload would now would prevent me from doing much in the way of coding even if I can obtain the docs for the S3 968 and IBM 524/526. -Toth Ani Joshi is working on legacy S3 support. Several of the chipsets are supported in xfree86 cvs, although I can't list which ones off the top of my head. -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI r128 and documentation
On Die, 2002-10-29 at 14:27, Aymeric Vincent wrote: I have an iBook with a r128 LF. The video output in mirroring mode is broken (recognizable but waves horizontally). I could manage to make it work in 256 colours by switching to using the second CRTC (and feeding it with the right values), but I failed to make it work in 15/16/24 bit modes. I contacted ATI in order to get documentation, so that I could improve the situation and also prepare some patch that wouldn't break other cards which may not have a second CRTC (?). However I got no reply so far. Can anyone on this list help me, at least get in touch with them? I am willing to sign an NDA if need be. From what I saw, it looks like the R128 LF is much like a radeon chip as far as dual-head is concerned: it looks like it should be easy to add Xinerama support to the r128 driver. The registers for the second hardware cursor do exist and work, the two different offset registers work as expected, etc. It's also my impression that dualhead support shouldn't be hard to add looking at the radeon driver. In fact, it might be doable without docs, someone even posted a quick'n'dirty but untested patch here. If you absolutely need to consult documentation for something, I'll gladly look it up. And once you've achieved something, ATI might be less hesitant to provide the docs to you. There still seem to be quite a lot of Rage128 users who'd certainly appreciate your work! -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trio 64 3D
Frank v Waveren wrote:
I'm having some trouble getting a Trio 64 3D AGP working with XFree86
4.2.0. With the config XFree86 generates the screen flashes on
startup and then stays black. The log gives this:
(++) Using config file: /root/XF86Config.new
Trio3D -- Display is on...turning off
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x3a807f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x00915f80
Trio3D -- GE was on ST#1: 0x20007f80 ST#2: 0x20007f80
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x3a007f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x3e915f80
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x20007f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x20007f80
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x20007f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x20007f80
Trio3D -- GE was on ST#1: 0x20007f80 ST#2: 0x20007f80
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x35007f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x38115f80
Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x20007f80
Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations
Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x20007f80
Hmm, that's a rather cut down version of the log. Do you have a fully
copy posted somewhere we can download it?
Also, what version of xfree86 is this and what distro?
You might have better results with version 1.8.2 from
http://www.user1.netcarrier.com/~kbrosius/pages/virge.html . But I'm
not sure without knowing what you are running already.
At which point it hangs, unkillable by anything but SIGKILL.
(The screen stays black and switching back to a vt with chvt(1)
doesn't give any visible results).
Stracing the process gives an infinite loop of:
read(5, , 4) = 0
select(1024, [5], NULL, NULL, {0, 0}) = 1 (in [5], left {0, 0})
(fd 5 is /dev/null)
The full log should show the mouse problem you mention in your second
email. Although unless AllowMouseOpenFail is set, it should not hang.
Normally a mouse failure will return you cleanly to the console assuming
you are not using xdm. How are you starting X?
Even with the vesa driver I cannot get anything displayed.
Here is the lspci output:
01:00.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01) (prog-if 00 [VGA])
Subsystem: S3 Inc. 86C365 Trio3D AGP
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at e000 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at unassigned [disabled] [size=64K]
Capabilities: [44] Power Management version 1
The system is a Pentium II on an ABIT LX6 motherboard (based on the
intel 440LX chipset).
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
--
Kevin
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI Radeon IGP
To List: Does XFree support the ATI IGP chipsets? I've tried the latest (4.2.0, 4.2.1, 4.2.99 [from CVS]) and have different kinds of crashes, from server sig 11 to server hangup to system hangup. Luckily, the fbdev driver works well but excuse me for being a pig, I want accelerated 3-D! According to the manufacturers, the IGP is a built-in radeon. The problem is the XFree radeon driver hasn't worked. I haven't been able to contact ATI directly on this. Is there an ATI patch for the source I can apply. Is it supported but with special XF86Config options called out? For reference, I've attached what I thought might be useful files. ...Dan ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! XF86Config.new Description: Binary data pci bus 0x cardnum 0x00 function 0x00: vendor 0x1002 device 0xcab0 ATI Device unknown pci bus 0x cardnum 0x01 function 0x00: vendor 0x1002 device 0x700f ATI Device unknown pci bus 0x cardnum 0x07 function 0x00: vendor 0x1106 device 0x0686 VIA VT 82C686 MVP4 ISA Bridge pci bus 0x cardnum 0x07 function 0x01: vendor 0x1106 device 0x0571 VIA VT 82C586 MVP3 IDE Bridge pci bus 0x cardnum 0x07 function 0x02: vendor 0x1106 device 0x3038 VIA VT 82C586 MVP3 USB Controller pci bus 0x cardnum 0x07 function 0x03: vendor 0x1106 device 0x3038 VIA VT 82C586 MVP3 USB Controller pci bus 0x cardnum 0x07 function 0x04: vendor 0x1106 device 0x3057 VIA VT 8501 MVP4 ACPI Bridge pci bus 0x cardnum 0x07 function 0x05: vendor 0x1106 device 0x3058 VIA VT 8501 MVP4 MultiMedia pci bus 0x cardnum 0x0b function 0x00: vendor 0x10ec device 0x8139 Realtek RTL8139 10/100 Ethernet pci bus 0x0001 cardnum 0x05 function 0x00: vendor 0x1002 device 0x4136 ATI Radeon IGP xfree.log Description: Binary data
Re: [Xpert]Re: But *why* no vblank?
Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: Oh, and are there any opinions about the signal to use, SIGALRM or something else? You'll have to make it settable -- SIGALRM is already used by the X server for scheduling. Of course, we could eliminate that if I could get the current time of day mapped into the X server address space :-) * The interface needs to provide a vblank counter, so the user can easily detect dropped vblanks. Has been there from day 1. I wonder what to do about this for the signal though, put the sequence number into the siginfo (is that possible?), or is the information you get back from the ioctl enough? It would be nice to get it without another syscall; there's certainly enough space in the siginfo to pass it along. I assume you'd pass along the current counter value and not some kind of delta. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Sorry about the double posts!
___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
Le dim 03/11/2002 à 18:47, Keith Packard a écrit : Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: Oh, and are there any opinions about the signal to use, SIGALRM or something else? You'll have to make it settable -- SIGALRM is already used by the X server for scheduling. Of course, we could eliminate that if I could get the current time of day mapped into the X server address space :-) Just synchronizing from time to time and using TSC in the meantime isn't sufficient ? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nv driver crash on nForce
On Fri, 2002-11-01 at 12:33, Vasco Alexandre Da Silva Costa wrote: The XFree86 drivers in the XFree86-4.2.0-72 RPM package which comes with RedHat 8.0 do not work with nForce properly. As mentioned in RedHat bug 75018, Mike Harris has a new build from CVS at ftp://people.redhat.com/mharris . This build fixes the nForce crash but introduces a new bug where (at least) the Mozilla throbber and scrollbars become garbled. Still, it eliminates the need for using the -ignoreABI parameter. --- snip --- Thank you, I was getting tired of having X server problems with those buggy NVIDIA drivers. :-) Huge thanks from me to the people involved as well. Best regards, Mikkel Lauritsen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]radeon 9000pro refuses to work
Last week i bought a gigabyte radeon 9000 pro that worked fine using the chipid of a radeon 8500. The radeon had some problems and was replaced by another radeon 9000 pro, this time one made by powercolor. But this one refuses to work with the exact same configuration of the gigabyte. I have to diferent errors: 1- if i use the line BusID PCI:1:0:1 i get this error: [chico@athlon chico]$ x XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-23mdkenterprise i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Nov 4 16:41:46 2002 (==) Using config file: /etc/X11/XF86Config-4 Using vt 7 (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:0) found (EE) RADEON(0): Cannot read V_BIOS (EE) RADEON(0): No valid MMIO address (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. 2-If i don't use that line or use BusID PCI:1:0:0 my monitor losts signal (goes standby) and i have to reset the computer. I got no error in the log. I tried the chipid of radeon VE, radeon7500 and radeon 8500, all with the same results. The card works if i use the vesa or the fbdev driver. I send in attach my XF86Config. I'm using mandrake 9.0 and xfree4.2.1. I'm out of ideas, is this a card specific problem? Thanks. -- Francisco Castanheiro EMail: [EMAIL PROTECTED] A sua loja online: www.shopizzy.com The wise man doesn't give the right answers, he poses the right questions. # File generated by XFdrake. # ** # Refer to the XF86Config(4/5) man page for details about the format of # this file. # ** Section Files RgbPath /usr/X11R6/lib/X11/rgb # Multiple FontPath entries are allowed (they are concatenated together) # By default, Mandrake 6.0 and later now use a font server independent of # the X server to render fonts. FontPath unix/:-1 EndSection # ** # Server flags section. # ** Section ServerFlags # Uncomment this to cause a core dump at the spot where a signal is # received. This may leave the console in an unusable state, but may # provide a better stack trace in the core dump to aid in debugging #NoTrapSignals # Uncomment this to disable the CrtlAltBS server abort sequence # This allows clients to receive this key event. #DontZap # Uncomment this to disable the CrtlAltKP_+/KP_- mode switching # sequences. This allows clients to receive these key events. #DontZoom # This allows the server to start up even if the # mouse device can't be opened/initialised. AllowMouseOpenFail EndSection # ** # Input devices # ** # ** # Keyboard section # ** Section InputDevice Identifier Keyboard1 Driver Keyboard Option AutoRepeat 250 30 Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout pt EndSection # ** # Pointer section # ** Section InputDevice Identifier Mouse1 Driver mouse Option ProtocolIMPS/2 Option Device /dev/usbmouse Option ZAxisMapping 4 5 #Option Emulate3Buttons #Option Emulate3Timeout50 # ChordMiddle is an option for some 3-button Logitech mice #Option ChordMiddle EndSection Section Module # This loads the DBE extension module. Loaddbe # This loads the Video for Linux module. Loadv4l # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that
Re: [Xpert]G200 Xv problems
On Wed, Oct 30, 2002 at 02:06:57AM -0500, Gary Steele wrote: I've been having some strange troubles with Xv on my MGA G200 card. Specifically, I get black flickery vertical lines down the right hand side of the xv image whenever playing larger video files. will show this funny black line symptom. Note that the black lines are still there if the movie is paused, and are still flickering/moving. (It's actually present when I first load xine and it puts up the xine logo in the display window...) Has anyone else had this problem with the G200? I'm wondering if it's the driver or if my hardware is flaky. Here's my pci entry: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 03) I have 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) and I've never seen such a problem, with any XFree86 version I tried (4.0, 4.1, 4.2). Only that with 4.2, Xv for big images doesn't work, because drm allocates too much video RAM for itself (see also my earlier message on this topic). You might try the suggested workaround of setting Option TexturedVideo; it seems to change some things for Xv. Maybe there's also a difference between rev 01 and rev 03? -- Andreas Trottmann [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: No DRI for Dual-headed setup?
[ First off, it's better to post to a DRI list about the DRI ] Yes, I'll post my questions to [EMAIL PROTECTED] Fortunately, I can't do that comparison here, but it's pretty fast, even with a window that covers the whole screen. Does the lack of perfect smoothness bother you? Note that the window manager can make a huge difference there, e.g. sawfish was much worse than metacity here. Perfection has always been my demand. I use openbox; I've tried other wm's, including metacity, and I get the same results. still, I'd expect smooth window refresh from such a hefty peice of software as XF86..? I've seen quite a number of other people complain about this as well. In fact, a friend of mine who owns an older radeon says he's got great 3d accel but no 2d accel, and wishes for a window manager that uses pure glx. It would be possible, but who's got time to code it :-P The 3D driver has absolutely no notion of a shared entity yet. What should work would be implementing dualhead with a single framebuffer on top of the CloneDisplay support in current CVS. but I'd have to do it myself the lack of dri in dualhead and the fact that you have to restart X to change the dualhead setup seriously hampers things, as you can imagine. cheers, Kacper ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Bug with virtual screen panning and mouse positioning
On 29 Oct 2002, Gregory Stark wrote: I reported a bug a while ago and didn't receive any response. In recent releases of 4.2.1 the behaviour has changed slightly. The change in behaviour makes me suspect somebody might think they've fixed the bug but in fact it's still present. The problem manifests when in a screen size smaller than the frame buffer size. So for example I normally operate in 1600x1200 but sometimes switch resolution to 800x600 or 640x480 and pan around with the mouse to see small details clearly. When I do this I often see something weird. A small slice of the right side of the screen shows pixels from elsewhere on the frame. For example, right now I'm in 1280x1024 with a 1600x1200 frame buffer, and the rightmost 4 pixels are showing the slice of pixels that also appear 769 from the left of the screen. Ie, as I move windows around in the middle of the screen when they pass the 769 mark i see them on the right edge as well. The hardware mouse does not appear there. However another bug occurs with the mouse. When I hit the edge and the screen pans the mouse hotpoint doesn't stay synced with the pointer. This has the result that whenever I'm in a reduced screen resolution the mouse hotpoint has a random displacement relative to the pointer of up to 4 pixels. This is obvious if you drag an object to the edge, you can see the object move while the mouse stays still, then the screen pans and the mouse leaps ahead of the object. This used to be 8 pixels and the exact behaviour of the hotpoint when panning was subtly different. That's why I suspect somebody may have already tried to fix this bug and the fact that it's been around so long leads me to suspect perhaps they think they fixed it. In fact if anything it's gotten worse with the new problem of the incorrect pixels appearing at the edge. The log shows you are only using the Matrox adapter. So, a few questions arise: - Do you see the same problems using the Mach64 GT? - WRT the mouse problem with the Matrox, what effect does Option SWCursor have? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Changing ctrl-alt-bckspc to ctrl-alt-delete
[EMAIL PROTECTED] wrote: Making a generic method by which you could send an arbitrary string (defined in a keymap) to a driver does seem like a flexible method for handling this sort thing though, so maybe I'll look into it when I finish some current projects. That's in about what I thought of, so I'd really appreciate! Thomas -- Thomas Winischhofer Vienna/Austria mailto:thomas;winischhofer.net *** http://www.winischhofer.net ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
Xavier Bestel [EMAIL PROTECTED] writes: Le dim 03/11/2002 à 18:47, Keith Packard a écrit : Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: Oh, and are there any opinions about the signal to use, SIGALRM or something else? You'll have to make it settable -- SIGALRM is already used by the X server for scheduling. Of course, we could eliminate that if I could get the current time of day mapped into the X server address space :-) Just synchronizing from time to time and using TSC in the meantime isn't sufficient ? Note that SMP issues make using the TSC safely really hard .. TSC's aren't synchronized between processors on SMP systems, and a process could get migrated at any time. I think the Linux kernel people aren't yet sure if it's possible to do a safe non-syscall high-resolution gettimeofday() for these reasons. Making the signal settable is definitely the right thing to do in any case. What the /dev/rtc driver does is hook into SIGIO so it can use fnctl (fd, F_SETSIG, ...); that setup could probably be copied, though there may be better ways of doing it. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]private mailing lists - an archive or read only access?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Nov 2002 00:20, Juliusz Chroboczek wrote: Let's face it -- it already takes A$1.8 to get a green note. I think it may be a good idea to move user support to ``xpert'', make ``devel'' public and move XFree86 development to it, and create a new ``private'' list for internal announcements only. Naming the new list ``private'' would have the additional advantage of reminding people what it is for. The Linux USB group (and probably a ton of others) have linux-usb-devel: for questions about Linux USB development linux-usb-users: for questions about Linux USB usage. There is very occasional private email (either that, or I'm not on the list:-) between developers. There are two private lists that I know of - one for the mass-storage stuff (some NDA issues, I think), and one for our slush fund (the Beanie award) discussions. We get occasional cross-posting and a few people who think -devel is a way to get help from a developer, rather than a way to do development, but it mostly works OK. If you choose to answer a question on the wrong list, adding however this probably should have gone to -X list can help. Might be a model worth following? Brad BTW: Don't forget that the Beanie fund is trying to get rid of its cash - if you need money to get toys, see http://www.linux-usb.org/beanieForm.html - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9xY9aW6pHgIdAuOMRAmXnAKCIVI1DCut30x83bHtcsKurAzgT5ACgqacD ZtzMWnOPG1wO/Q4JOwP0qcQ= =Selj -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nv driver crash on nForce
On 3 Nov 2002, Mikkel Lauritsen wrote: On Fri, 2002-11-01 at 12:33, Vasco Alexandre Da Silva Costa wrote: The XFree86 drivers in the XFree86-4.2.0-72 RPM package which comes with RedHat 8.0 do not work with nForce properly. As mentioned in RedHat bug 75018, Mike Harris has a new build from CVS at ftp://people.redhat.com/mharris . This build fixes the nForce crash but introduces a new bug where (at least) the Mozilla throbber and scrollbars become garbled. Still, it eliminates the need for using the -ignoreABI parameter. What's this? I know of no rendering problems on nForce. Did it detect the amount of video ram correctly? Ie. the server reports the amount configured in the bios? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Trio 64 3D
First of all, thanks for taking the time to help. On Sun, Nov 03, 2002 at 10:27:52AM -0500, Kevin Brosius wrote: Hmm, that's a rather cut down version of the log. Do you have a fully copy posted somewhere we can download it? Sure, forgot it might help for the updated problem. http://www.var.cx/XFree86.0.log. Also, what version of xfree86 is this and what distro? I think I mentioned at the top it's 4.2.0, and it's from an rpm from redhat 8.0 You might have better results with version 1.8.2 from http://www.user1.netcarrier.com/~kbrosius/pages/virge.html . But I'm not sure without knowing what you are running already. This appears to list only 4.1 drivers and earlier, I assume that the changes listed here have been absorbed into 4.2, correct? Normally a mouse failure will return you cleanly to the console assuming you are not using xdm. How are you starting X? Yeah, I forgot AllowMouseOpenFail too.. I'm running it by calling XFree86 -xf86config /root/blah -terminate directly. Even with the vesa driver I cannot get anything displayed. This is no longer true since I fixed the mouse, vesa works fine now (which is already reason for minor rejoicing). -- Frank v Waveren Fingerprint: 21A7 C7F3 fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 1FF3 47FF 545C CB53 Public key: hkp:[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Support for ATI radeon 7500 with id 4336.
Title: RE: [Xpert]Support for ATI radeon 7500 with id 4336. I would qualify your graphics chipset as an M6 compatible device. (I dont have a Laptop.) Lets hope that helps you to find a driver and make this device running. -Alex. -Original Message- From: Christer Backstrom [mailto:[EMAIL PROTECTED]] Sent: Monday, October 28, 2002 19:57 To: [EMAIL PROTECTED] Subject: [Xpert]Support for ATI radeon 7500 with id 4336. Hello, On my new compaq evo N5001v, there's supposedly a radeon 7500 card. The card woun't work with the either the radeon or ati driver, though. Is there any way to use this card (OK, I'm using the vesa driver for now, but I mean natively), or is support under way? I'm attaching lspci -xxx and lspci -vvv if someone is interested. Cheeres, /Chris
Re: [Xpert]Trio 64 3D
Frank v Waveren wrote: First of all, thanks for taking the time to help. On Sun, Nov 03, 2002 at 10:27:52AM -0500, Kevin Brosius wrote: Hmm, that's a rather cut down version of the log. Do you have a fully copy posted somewhere we can download it? Sure, forgot it might help for the updated problem. http://www.var.cx/XFree86.0.log. Have you tried depth 16 and a larger mode, say 800x600? Not that depth 8 shouldn't work, but I'm curious. Also, does your XF86Config file contain a 'set_mclk' parameter (or variant with mclk in it)? How about the monitor section of your XF86Config, does it contain entries for 'Horizsync' and 'Vertrefresh'? Also, what version of xfree86 is this and what distro? I think I mentioned at the top it's 4.2.0, and it's from an rpm from redhat 8.0 Ah, yes. Missed it. You might have better results with version 1.8.2 from http://www.user1.netcarrier.com/~kbrosius/pages/virge.html . But I'm not sure without knowing what you are running already. This appears to list only 4.1 drivers and earlier, I assume that the changes listed here have been absorbed into 4.2, correct? Yes, never mind. -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
On Sun, Nov 03, 2002 at 03:00:53PM +0100, Michel D?nzer wrote: On Son, 2002-11-03 at 06:17, Elladan wrote: It might be best to provide both interfaces. It's probably not significantly harder to provide both API's - they both trigger off the same hardware event. Yes, I'm looking into adding a flag to the ioctl so it sends a signal instead of blocking. Shouln't be too hard, but I haven't found out yet whether a signal can be delivered from an interrupt top half, if anyone knows I'd appreciate letting me know before I find out the hard way. :) Oh, and are there any opinions about the signal to use, SIGALRM or something else? Definitely want to make this configurable. All the normal signals are used for something already. Otherwise, SIGUSR1/2 would be the best choice... And no, I don't think a signal can possibly be delivered in the top half, by the way. It's going to get delayed by the userspace transition just as much as a blocking system call would (probably more), so mostly I think it's just a tool for single-threaded apps to handle vblanks. I could be wrong about that, but I think you'd need rtlinux style extensions to the kernel to achieve direct interrupt deliveries to user-space (and you'd need to be root, and such). This means, of course, that the kernel has to be low-latency for any of this to work all that well, except for the in-kernel command idea below (and probably even that). But, that's sort of unavoidable. Nice but not as important: * It would be nice if the interface provided a way to request the current scan line, and block on particular scan lines. Hardware which didn't support this (eg., LCD monitors, less-good video cards, etc.) would of course be expected to return an error. What would that be useful for? As you've explained very well in your other post, the various latencies don't allow for such fine grained timing. Well, these wouldn't be useful in general purpose circumstances much, since very little hardware is going to support it. There might be some value to this in a few cases. For example, if I have video playing in a window, I don't technically care when the vblank happens. Rather, I care when the scan line passes the bottom of my window. Conceivably, someone on specialized hardware might want to make use of this, for instance, so they don't have to employ a double buffer for the video. Block on the bottom of the window, then redraw the window during the rest of the refresh. Querying the current scan line wouldn't be of that much use, I admit. One possible application is to check to see that you haven't incurred too much latency after performing some task. Eg., you block on a scan line, or the vblank, and then perform some actions. Then, just before doing something else, you check that the scan line isn't into your critical area yet. If it is, you block again rather than tear. For specialized applications, a realtime app that doesn't block, except perhaps on other realtime threads, might attain stable enough latencies that the sorts of video tricks people liked to do in the Amiga days would be possible again. Eg., poll the scan line at 30,000hz and fiddle with the video card multiple times during a frame. Again, not something that will ever work with modern desktop hardware, but perhaps on an embedded device. I threw these in more as an API issue than anything else. If there's no API for it, you can be certain that it'll get almost no support in drivers. On the other hand, APIs with no implementations tend to sort of wither and die, until someone decides they actually want it ten years later, and redesigns it... And of course, I can't actually imagine a case where these would be useful on anything except specialized hardware, so most likely it's just a non-issue. People with such hardware will probably be writing the drivers as well. * It would be nice if the interface provided a way to latch particular simple actions, such as a buffer flip, to the interrupt directly. For example, with an ioctl: vbc.action = VB_SWAP_BUFFERS; vbc.arg1 = BUFFER1_TOKEN; vbc.arg2 = BUFFER2_TOKEN; ioctl(vblankdev, WAIT_FOR_VBLANK_AND_DO_SOMETHING, vbc); Here, the ioctl blocks until the vblank, and the driver performs the command in the interrupt handler if possible. Not sure about this. I've played with doing this for flips in the radeon 3D driver, and it didn't work out all that well. Granted, I didn't do the flip in the interrupt top half, but I'm not sure if that's feasible. Well, the basic advantage to this is that a low-latency kernel should be able to run the interrupt bottom half within a fixed amount of time, wheras it may not be able to return to a non-root userspace quickly. For example, say I'm not root, and I try to block on the vblank and then flip. This won't work, because I can't lock myself in ram, and I can't put myself in a realtime priority class - so, the
[Xpert]G200 Xv problems
Just wanted to add my 2 cents here - I've been experiencing this /exact/ problem too, and I have a Rev 01 G200.. Sample pic at http://gdh.ca/~gdh/pics/xvcorrupt.jpg However, I wouldn't be surprised if it was a bandwidth issue, or bus contention... since I have .. um.. quite a few PCI cards: lindesk:~# lspci 00:09.0 Ethernet controller: 3Com Corporation 3c595 100BaseTX [Vortex] 00:0b.0 Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 01) 00:0d.0 SCSI storage controller: Adaptec AIC-7881U 00:0f.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 02) 00:11.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) The 'SAA7146' is a Nova-T digital TV receiver card... I'm using Debian 3.0 with XFree86 4.1... I've rolled my own kernel and am using the mga driver in X (as opposed to the vesafb one), although I'm absolutely certain the problem was there even before I did my own kernel... Not sure what help I can be, but at least the revision 01 cards are also vunerable Cheers, Gavin. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 gdb for Linux PPC?
Is there an XFree86 module-aware version of gdb for Linux PPC someplace? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, Nov 01, 2002 at 10:41:33PM +0100, [EMAIL PROTECTED] wrote: If one knew the time until vblank, one could simply wait that time, and then do a xsync. It could really be that simple. You can't sleep with that level of precision. That depends entirely on which OS and which kernel. Even if you could, there will be latency between when your timer expires and when you wake up. Sure. Then time that, and compensate. You also don't know how much latency there was from the time you asked until the time you went to sleep, so you've added two unknown latencies together. Finding the time through a simple function call takes microseconds, so it is not a problem. If network overhead is a problem, the function should be local but synchronized with the screen. If you assume the worst-case latency of even a low-latency patched system is ~1.5ms, then adding two together gives you ~3ms. The vertical blanking period itself is in this range of time. You assume wrongly that things must happen in the vertical blanking period. Since the screen is traced from the top on monitors, all an operation has to do to get a flickerfree update, is to not collide with the screen tracing. F.ex. it could draw the upper part of the screen when the lower is traced, and vice versa. There are lots of other solutions to this same problem. You also don't know how accurate the timer counting to the next vblank is. Perhaps it's off. That argument can be applied to ANY function, so it is irrelevant. Besides, accuracy of timers can be measured. The only reasonable interface here is to grab a kernel object directly, and somehow block until the vblank (probably best all around), or schedule a signal to be delivered after the vblank interrupt goes off. That way, you trigger directly off the event, and you only incur one unavoidable period of latency. So, you want all operating systems to change their kernels to support one particular X11 function. That is a very unlikely prospect. And why not instead use a functionality that nearly all operating systems have, namely timer trigged interrupts and signals? Just synchronize the vblank timing with a timer from the operating system, and you get just what you want: a kernel delivered interrupt or signal. [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Elladan: The number of ms till the next vblank will be a number between 0 and 17, usually nor more than 12 or so. It cannot be accurate to more than 3ms or so if it comes from the X server. The minimum time most systems can sleep is on the order of 10ms, and the precision they can sleep at is also on the order of 10ms. This isn't powerful enough for *any* purpose as far as I can see. Well, I can see plenty of purposes it is powerful enough for. F.ex. retracing of the screen without causing flicker. A screen update can be timed, and positioned in time as to minimalize the collision with the screen update. F.ex. if the screen retrace time is 15ms, and drawing on that screen takes 20ms, and the drawing starts when the screen is traced about halfway, then the bottom of the drawing of the pixmap will reach the bottom of the screen a little after the screen starts to retrace from the top, thus avoiding flicker. | \ \ \ | \ \ \ \ | \ \ \ | \ \ However, if what you want is to emulate an Amiga with its COPPER and CLIPPER chips which were specially built for precise cathode ray position based operations, I suggest you give up on interrupt based stuff, and instead just renter an Amiga screen in 24 bit per pixel. Kim0 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: No DRI for Dual-headed setup?
Well, what I personally wish was possible with DRI and dual head, is to have the pixmap of 1 screen spread over 2 monitors, and have 3 of these big screens spread over my 6 monitors. I guess that rendering of X would go twice as fast, when X commands only has to be triplicated instead of hexplicated? [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
