Re: [Xpert]Trident Cyber/BladeXP LCD Panel size (i830MG too)
Hi Adam! I am having the exact same problem with firing up an LCD in 1400x1050 with HP Pavilion N5495 and the Intel 830MG chipset. It seems as though i810 driver completely ignores any ModeLines passed to it, and insists on using VESA modes. Is that right? If so is it possible to change this behaviour and fire it in 1400x1050 mode (which is a perfectly valid VESA mode BTW)? If it's neccassary I am willing to do testing of the code. You are correct about the i830 driver. The problem is that the BIOS for the 830 chipset is pretty much broken in many ways. One of the problems is that when you do a mode set and specify the ModeInfoBlock structure so that you can set non-VESA modes, it completely ignores it. In fact, it's so broken that you have to set 60Hz modes (the others don't work) and then switch to other refresh rates using another BIOS call. Unfortunately that allows you to only set 56, 60, 70, 72, 75, 85, 100, 120, and 43 Hz interlaced. The resolutions is also limited to VESA modes. All of this can be solved by not using the BIOS to set modes, but Intel (who sponsored the development of the 830M driver) discourages that approach. In answer to your 1400x1050 question: The 830 Video BIOS doesn't support 1400x1050. I just looked through the data sheet again, so you're out of luck there. -- Regards Abraham Hors d'oeuvres -- a ham sandwich cut into forty pieces. -- Jack Benny __ Abraham vd Merwe - 2d3D, Inc. Device Driver Development, Outsourcing, Embedded Systems Cell: +27 82 565 4451 Snailmail: Tel: +27 21 761 7549Block C, Antree Park Fax: +27 21 761 7648Doncaster Road Email: [EMAIL PROTECTED] Kenilworth, 7700 Http: http://www.2d3d.comSouth Africa PGP signature
[Xpert][patch] DGA 2.0 fix for radeon
radeon driver (both 4.1.0 and CVS) have a problem with DGA 2.0.
17 weeks ago, I made a patch for radeon_dga.c and sent it to
[EMAIL PROTECTED]
David Dawes [EMAIL PROTECTED] sent me a response from radeon driver
maintainer. I read the comments, made a new patch and sent it to him.
He kindly submitted it to [EMAIL PROTECTED] more than 5 weeks ago.
But it's still pending.
So I'm posting my patch(A.585) to this mailing list.
I hope this is helpful to someone.
Shyouzou Sugitani [EMAIL PROTECTED]
[EMAIL PROTECTED]
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dga.c.distSun Sep 9
08:44:33 2001
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dga.c Sun Sep 9 09:25:33
+2001
@@ -76,74 +76,68 @@
RADEONInfoPtr info= RADEONPTR(pScrn);
DGAModePtr newmodes= NULL, currentMode;
DisplayModePtr pMode, firstMode;
-intotherPitch, Bpp = bitsPerPixel 3;
+intsize, pitch, Bpp = bitsPerPixel 3;
Bool oneMore;
-pMode = firstMode = pScrn-modes;
-
-while (pMode) {
- otherPitch = secondPitch ? secondPitch : pMode-HDisplay;
-
- if (pMode-HDisplay != otherPitch) {
- newmodes = xrealloc(modes, (*num + 2) * sizeof(DGAModeRec));
- oneMore = TRUE;
- } else {
- newmodes = xrealloc(modes, (*num + 1) * sizeof(DGAModeRec));
- oneMore = FALSE;
- }
-
- if (!newmodes) {
- xfree(modes);
- return NULL;
- }
- modes = newmodes;
-
SECOND_PASS:
- currentMode = modes + *num;
- (*num)++;
+pMode = firstMode = pScrn-modes;
- currentMode-mode = pMode;
- currentMode-flags = DGA_CONCURRENT_ACCESS;
- if (pixmap)
- currentMode-flags |= DGA_PIXMAP_AVAILABLE;
- if (info-accel) {
- if (info-accel-SetupForSolidFill
- info-accel-SubsequentSolidFillRect)
- currentMode-flags |= DGA_FILL_RECT;
- if (info-accel-SetupForScreenToScreenCopy
- info-accel-SubsequentScreenToScreenCopy)
- currentMode-flags |= DGA_BLIT_RECT | DGA_BLIT_RECT_TRANS;
-
- if (currentMode-flags
- (DGA_PIXMAP_AVAILABLE | DGA_FILL_RECT |
- DGA_BLIT_RECT | DGA_BLIT_RECT_TRANS))
- currentMode-flags = ~DGA_CONCURRENT_ACCESS;
- }
- if (pMode-Flags V_DBLSCAN)
- currentMode-flags |= DGA_DOUBLESCAN;
- if (pMode-Flags V_INTERLACE)
- currentMode-flags |= DGA_INTERLACED;
- currentMode-byteOrder = pScrn-imageByteOrder;
- currentMode-depth = depth;
- currentMode-bitsPerPixel = bitsPerPixel;
- currentMode-red_mask = red;
- currentMode-green_mask = green;
- currentMode-blue_mask = blue;
- currentMode-visualClass= visualClass;
- currentMode-viewportWidth = pMode-HDisplay;
- currentMode-viewportHeight = pMode-VDisplay;
- currentMode-xViewportStep = 8;
- currentMode-yViewportStep = 1;
- currentMode-viewportFlags = DGA_FLIP_RETRACE;
- currentMode-offset = 0;
- currentMode-address= (unsigned char*)info-LinearAddr;
-
- if (oneMore) { /* first one is narrow width */
- currentMode-bytesPerScanline = (((pMode-HDisplay * Bpp) + 3)
- ~3L);
- currentMode-imageWidth = pMode-HDisplay;
- currentMode-imageHeight = pMode-VDisplay;
+while (1) {
+ pitch = pScrn-displayWidth;
+ size = pitch * Bpp * pMode-VDisplay;
+
+ if ((!secondPitch || (pitch != secondPitch))
+ (size = info-FbMapSize)) {
+
+ if (secondPitch)
+ pitch = secondPitch;
+
+ if (!(newmodes = xrealloc(modes, (*num + 1) * sizeof(DGAModeRec
+ break;
+
+ modes = newmodes;
+ currentMode = modes + *num;
+
+ currentMode-mode = pMode;
+ currentMode-flags = DGA_CONCURRENT_ACCESS;
+
+ if (pixmap)
+ currentMode-flags |= DGA_PIXMAP_AVAILABLE;
+
+ if (info-accel) {
+ if (info-accel-SetupForSolidFill
+ info-accel-SubsequentSolidFillRect)
+currentMode-flags |= DGA_FILL_RECT;
+ if (info-accel-SetupForScreenToScreenCopy
+ info-accel-SubsequentScreenToScreenCopy)
+currentMode-flags |= DGA_BLIT_RECT | DGA_BLIT_RECT_TRANS;
+ if (currentMode-flags
+ (DGA_PIXMAP_AVAILABLE | DGA_FILL_RECT |
+ DGA_BLIT_RECT | DGA_BLIT_RECT_TRANS))
+ currentMode-flags = ~DGA_CONCURRENT_ACCESS;
+ }
+ if (pMode-Flags V_DBLSCAN)
+ currentMode-flags |= DGA_DOUBLESCAN;
+ if (pMode-Flags V_INTERLACE)
+
Re: [Xpert]pseudocolor support in 24 bit depth?
On Tue, 23 Oct 2001, Mark Vojkovich wrote: On Tue, 23 Oct 2001, Matt Wilbur wrote: Hi all, Does anyone know if there's plans to make pseudocolor visuals available in modes 8 bit? We're saddled with some grotty old apps (saoimage, for one) that still work great, provided you display them to an X server that supports pseudocolor visuals in 24 bit mode... but that excludes XFree86 currently. IRIX's X server and Exceed7 on LoseNT boxes seem to do OK, and it looks like AccelX claims to, but we'd sure like to do this on XFree.. I don't know that there are any plans to hack this. It's not worth the effort in my opinion. It's a mess and the problems are with the apps, not the server. It's a TrueColor world. Doesn't the RandR extension give us multiple simultaneous depths ? Matt, only a few drivers support it so far (check the archives for which ones). IIRC one of the generic drivers does work, so you can run the extendision on most cards, if you don't mind loosing acceleration. While I don't know of any plans, and I agree that the app is indeed the problem, I think the hack to implement PseudoColor on DirectColor should not be too hard - at depth 24 the two visuals are just different ways of interpreting the colormap. I have thought of adding this to xnest, so that it would be available to every driver, but not get in the way of ordinary users - once you use pseudocolor you will see why most people are better off without it. -- 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]Last review of xfree86.
Hello, I am trying to install redhat 7.1 in a notebook with a mobility radeon graphic card, but I cannot do it with the last released version of xfree86 (version 4.1.0). I know that if I want to get the very last version, I have to download version 4.1.0 and make a CVS check of it, but I don´t have an ethernet connection and it takes ages. Does somebody knows of some other way to get the very last version ? Is it any ftp site where I could download the very last version without making a CVS check ? Thanks Hanyo. _ Hämta MSN Explorer kostnadsfritt på http://explorer.msn.se ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Matthew Reppert wrote: Michel Dänzer wrote: On Tue, 2001-10-23 at 07:54, Matthew Reppert wrote: Now, let me say one thing; I've run two different kernels on this system: 2.4.10 and 2.4.12. Note #1: my /usr/include/linux and /usr/include/asm were NOT FHS compliant ... because I'd copied the data into those directories. Note #2: I did this back when I was running 2.4.10. Well, today I noticed this, kicked myself in the arse a few times, and made the proper symlinks ... recompiled just now and X seems to work fine. Heck, Quake 3 runs nice ... ^^; From FHS 2.3: 6.1.7 /usr/include : Header files included by C programs These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc. /usr/include/asm - /usr/src/linux/include/asm-arch /usr/include/linux - /usr/src/linux/include/linux So your system isn't based on glibc? I think you've found out the hard way why these really shouldn't be symlinks. ... you know, that's a good point. I *am* glibc-based, 2.2.x. Interesting; well, it may have had to do with some of the stuff I defined in host.def, though I can't really see what it would be ... No, I think the problem was clearly the kernel headers. I'll look into it when I have more time (sometime later this week). Still suspect the headers. And why not symlinks? Because as you have found out, you're in trouble if they are wrong (your copy of the kernel headers from an older version was no different than wrong symlinks). This has been discussed extensively on l-k. Look at the Debian glibc packages for a solution that works. -- 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
[Xpert]more mouse buttons - is there a patch?
Hi, I would like to support my mouse which has 5 buttons plus a wheel. I've configured X11 with a 7 buttons mouse and all events show up nicely when running xev. The problem is that the current version of X(Free) has only event names Btn?Up for ?=1..5 Has anybody ever patched the source to allow more (at least 7) button events? A short look at the sources shows that several places would have to be patched. Thanks for a hint. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik Institute of Technology, RWTH Aachen D 52056 Aachen, Germany ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]is this bye bye freeware?
http://www.lindows.com/ was wondering if this one gets his wil dont it affect the rest of linux/unix sosiety ? i just discoverd linux like 2 years ago and heeeyyy know what i love it one of the reasons i like it is cause not all the pepol use it and the few i know that are using it is like loveing it too :) But IF this new emulator is realsed wouldnt that be like, know what i dont have too rip gates any more lets all go linux insted, moving alot of the REAL big software companies down too linux -GREAT- no it isnt that good a thing cause if linux is hit by big software companies like MS and other, then they will go hmmm lets get payed... so we will stop handing out open source codes .. then the open source projects will die out slow but they will die :/ What will be left too the pepol that loved unix/linux? Aint we titeled too have our freeware and joy of having an easy OS too handel not that black nothing too see OS called Microsoft and there REAL expeciv software ? i Like linux the way it is not the way it could be.. :/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]is this bye bye freeware?
Title: RE: [Xpert]is this bye bye freeware? no cause for alarm... Linux has survived without the support of big companies. It'll survive even with their proprietary software. After all, Quake3 isn't exactly open source, now is it? -Original Message- From: Ø.W.T [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 11:35 AM To: [EMAIL PROTECTED] Subject: [Xpert]is this bye bye freeware? http://www.lindows.com/ was wondering if this one gets his wil dont it affect the rest of linux/unix sosiety ? i just discoverd linux like 2 years ago and heeeyyy know what i love it one of the reasons i like it is cause not all the pepol use it and the few i know that are using it is like loveing it too :) But IF this new emulator is realsed wouldnt that be like, know what i dont have too rip gates any more lets all go linux insted, moving alot of the REAL big software companies down too linux -GREAT- no it isnt that good a thing cause if linux is hit by big software companies like MS and other, then they will go hmmm lets get payed... so we will stop handing out open source codes .. then the open source projects will die out slow but they will die :/ What will be left too the pepol that loved unix/linux? Aint we titeled too have our freeware and joy of having an easy OS too handel not that black nothing too see OS called Microsoft and there REAL expeciv software ? i Like linux the way it is not the way it could be.. :/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]is this bye bye freeware?
Looks like another distribution to me.. Vladimir Dergachev On Wed, 24 Oct 2001, [iso-8859-1] Ø.W.T wrote: http://www.lindows.com/ was wondering if this one gets his wil dont it affect the rest of linux/unix sosiety ? i just discoverd linux like 2 years ago and heeeyyy know what i love it one of the reasons i like it is cause not all the pepol use it and the few i know that are using it is like loveing it too :) But IF this new emulator is realsed wouldnt that be like, know what i dont have too rip gates any more lets all go linux insted, moving alot of the REAL big software companies down too linux -GREAT- no it isnt that good a thing cause if linux is hit by big software companies like MS and other, then they will go hmmm lets get payed... so we will stop handing out open source codes .. then the open source projects will die out slow but they will die :/ What will be left too the pepol that loved unix/linux? Aint we titeled too have our freeware and joy of having an easy OS too handel not that black nothing too see OS called Microsoft and there REAL expeciv software ? i Like linux the way it is not the way it could be.. :/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XDM
Whoever I log in as using xdm it says 'Login Incorrect' What could cause a login to fail ?
Re: [Xpert]XDM
Around 17 o'clock on Oct 24, David Harris wrote: Whoever I log in as using xdm it says 'Login Incorrect' What could cause a login to fail ? Xdm is probably not using the right password options -- you might have MD5 passwords or shadow passwords enabled and xdm might not have support for those compiled in. [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pseudocolor support in 24 bit depth?
Around 11 o'clock on Oct 24, Mark Vojkovich wrote: I don't know that there are any plans to hack this. It's not worth the effort in my opinion. It's a mess and the problems are with the apps, not the server. It's a TrueColor world. Doesn't the RandR extension give us multiple simultaneous depths ? I'm not sure about that. Yes, RandR will (eventually) enable simultaneous pseudo and true color visuals on simple true color hardware (or even pseudo color hardware). You'll even be able to switch between accelerated pseudo color and accelerated true color. With the underlying rendering code now ready for this, adding the capability to the extension should be relatively straightforward. Porting the extension to the mainline XFree86 server is a separate (and much harder) issue. You have to do it with shadow buffers for every depth 8 window. Whenever you change the palette you have to redraw (retranslate) the 8 bit data. You won't pass the test suite if you can't read back the 8 bit data you've just written. In theory you could have any number of PseudoColor maps though. That's what RandR will do. Obviously run-time pseudo-color emulation is pretty slow, so applications needing it will run better if the display is switched to pseudo color mode. I've implemented this before and it does work, but pseudo color applications that do colormap animation are pretty much unusable without real pseudo color hardware. [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]please help me! (Matrox G400)
This is my system Intel Celeron 1067 Mhz 640Mb Ram Matrox G400 DualHead 16Mb Pioneer DVD Player scsi 3 ultra wide scsi ibm HDs Pinnacle studio pctv TV Card Creative Sound Blaster Live! Slackware Linux 8.0 Linux 2.4.12 Xfree 4.1.0 Driver matrox (from matrox web site) Mtrr activated in kernel ... The first (and much important) problem are my system's performances in playing DVD disks. Really i'm not able to obtain good smooth video stream. My Xfree log says... (i'm reporting only strange things): . . . (==) MGA(0): BIOS at 0xC (--) MGA(0): Video BIOS info block at offset 0x07CE0 (WW) MGA(0): Video BIOS info block not detected! (WW) MGA(0): Failed to set up write-combining range (0xd800,0x200) ...here write-combining seems not to be working . . . (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.1.0, module version = 1.2.0 (==) MGA(0): Write-combining range (0xd800,0x100) (II) MGA(0): I2C bus DDC initialized. ...here write-combining seems to be working (II) MGA(0): Monitor name: PHILIPS 109S (II) MGA(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 95 kHz, PixClock max 2550 MHz (II) MGA(0): end of I2C Monitor info (==) MGA(0): Using gamma correction (1.0, 1.0, 1.0) (==) MGA(0): Min pixel clock is 12 MHz (==) MGA(0): Max pixel clock is 300 MHz (II) MGA(0): Display 1: Using hsync range of 30.00-95.00 kHz (II) MGA(0): Display 1: Using vrefresh range of 50.00-160.00 Hz (II) MGA(0): Clock range: 12.00 to 300.00 MHz (II) MGA(0): Not using default mode 1024x768 (bad mode clock/interlace/doublescan) (II) MGA(0): Not using default mode 1600x1200 (hsync out of range) (II) MGA(0): Not using default mode 1792x1344 (hsync out of range) (II) MGA(0): Not using default mode 1856x1392 (hsync out of range) (II) MGA(0): Not using default mode 1920x1440 (hsync out of range) (==) MGA(0): Write-combining range (0xd800,0x100) ...even here write-combining seems to be working What does all this mean?!?! is my write combining working to improve my system's perforances? some lines after the log says: (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor=The XFree86 Project compiled for 4.1.0, module version = 0.1.0 Symbol vbeFree from module /usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved! (--) Depth 24 pixmap format is 32 bpp (==) MGA(0): Write-combining range (0xd800,0x100) (--) MGA(0): 16 DWORD fifo really i don't understand!!! doing cat /proc/mtrr i obtain: reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x2000 ( 512MB), size= 128MB: write-back, count=1 reg02: base=0x00f0 ( 15MB), size= 1MB: uncachable, count=1 reg03: base=0xd000 (3328MB), size= 128MB: write-combining, count=2 reg04: base=0xd800 (3456MB), size= 16MB: write-combining, count=3 and xfree sees my g400 at : (--) PCI: (0:18:0) BrookTree 848 rev 18, Mem @ 0xde002000/12 (this is my bt848 txcard) (--) PCI:*(1:0:0) Matrox MGA G400 AGP rev 4, Mem @ 0xd800/25, 0xda00/14, 0xdb00/23 2-nd question: 3d performance are not goot as user... i receive this message libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering if i login as root my 3d performances are very good and i don't receive the error message. How can i obtain 3d performances as user? Thank you very much Francesco Oppedisano ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pseudocolor support in 24 bit depth?
On Wed, 24 Oct 2001, Mark Vojkovich wrote: On Wed, 24 Oct 2001, Dr Andrew C Aitchison wrote: While I don't know of any plans, and I agree that the app is indeed the problem, I think the hack to implement PseudoColor on DirectColor should not be too hard - at depth 24 the two visuals are just different ways of interpreting the colormap. You have to do it with shadow buffers for every depth 8 window. Whenever you change the palette you have to redraw (retranslate) the 8 bit data. You won't pass the test suite if you can't read back the 8 bit data you've just written. In theory you could have any number of PseudoColor maps though. Can't you just put the 8 bits into each of the red, green and blue bytes in the DirectColor framebuffer ? Then the hardware palette will think it is doing 3 8bit-8bit lookups, but logically it will be doing 1 8bit-24bit lookup. Having to read the data back makes it tempting to use depth=8, bits_per_pixel=32 pixmaps. This will give you not only the fast colormap updates which apps which have a reason for pseudocolor need, but also the colormap flashing which dumb p.c. apps force on use. Generally an accurate implementation of pseudocolor. The cards that support 8+24 could get rid of colormap flashing on the (default?) TrueColor visual, if we don't mind losing gamma correction on TrueColor (The RAMdacs I've seen allow you use the spare byte to indicate Direct or True color for each pixel). -- 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]please help me! (Matrox G400)
On Wed, 24 Oct 2001, Francesco Oppedisano wrote: This is my system Intel Celeron 1067 Mhz 1067 MHz? Are you running an overclocked processor, and if yes, did you try running at the specified speeds ? SCSI can be picky about bus-speeds. -Yuri 640Mb Ram Matrox G400 DualHead 16Mb Pioneer DVD Player scsi 3 ultra wide scsi ibm HDs Pinnacle studio pctv TV Card Creative Sound Blaster Live! Slackware Linux 8.0 Linux 2.4.12 Xfree 4.1.0 Driver matrox (from matrox web site) Mtrr activated in kernel ... The first (and much important) problem are my system's performances in playing DVD disks. Really i'm not able to obtain good smooth video stream. My Xfree log says... (i'm reporting only strange things): [snip] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]GLIBC linking
Hi Newbie warning !! ;) I'm getting errors an error compiling Midori linux. The problem is that when compiling XFree86 links to GLIBC_2.2 which I have on my system but Midori links to GLIBC_2.1.3. Where in the XFree86 Makefile/s do I need to change the library name? or perhaps it is set in an environment variable that Midori changes, if so what is it's name? Thanks in advance Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: Xv hit list
On Wed, 24 Oct 2001, Sottek, Matthew J wrote: Mark, Billy, I was just about to implement this but after giving it some thought I'm not sure what it is that you want. 2) For interlacing, I like the idea of an XV_FRAME_TYPE attribute: 0 == frame, 1 == top field, 2 == bottom field. I'm worried about the DRI API possibly not supporting stride on texture blits (is this true?) and I'm not sure how to handle this for DMA transfers. How is this going to work. Are you expecting to make two XvShmPutSurface() calls, one for the top field and one for the bottom? Each time providing just one field of data? or providing an XImage with both fields but only using one? I don't see how that is different that just doing two XvShmPutImage's now and doubling the pitch and vertical scaling. Slight difference in that the client can't bias the top down a quarter pixel and bottom upward by a quarter pixels so they line up. And XvImages don't have a pitch to double. It's implied from the width just as XImages are. The benefit of the TOP_FIELD BOTTOM_FIELD is that you can provide a whole image and display only one field at a time. I.e. the data is interlaced in the XImage but shouldn't be displayed progressive since it will look like crap. I have a different idea that might work out better. Define these four things: XV_TOP_FIELD 0x1 XV_BOTTOM_FIELD 0x2 XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) XV_HOLD 0x4 Hmmm. That would probably work OK. I kindof like HOLD as 0x0 though (ie, no fields displaying and it makes the min-max 0-3 instead of 1-4). This probably also helps with 3:2 pulldown and the field repeat. Note that this introduces some slight uncertainty in the display since the overlay might not correspond to the window location when it comes time to actually display. But that's not going to be a big deal since the times are short and you get a delay now anyhow due to the overlay not going into effect until the retrace on most hardware. It introduces a larger lag between overlay and image when moving windows which isn't going to be a big deal. You can't do this for blitted video though. The cliplist is stale by the time you display. Not a problem though since blitted video are merely fallbacks. Mark. The it works like this. You do an XvShmPutImage() with the XV_FRAME_TYPE set to XV_HOLD. The image (progressive or interlaced) is copied to the server but not displayed. The you can at any time set XV_FRAME_TYPE to be XV_FRAME (show the image now, both fields) XV_TOP or XV_BOTTOM. This has the benefit of getting rid of the unknown delay between the XvShmPutImage and the overlay flip since they are now separated (as they are in XvMC) plus you can display just top or just bottom. The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means that apps using Xv without knowledge of this will just get a flip when they do an XvShmPutImage. Here is the process: get port, etc... set XV_FRAME_TYPE to XV_HOLD LOOP: XvShmPutImage() set XV_FRAME_TYPE to XV_TOP_FIELD (Top field shown asap) set XV_FRAME_TYPE to XV_BOTTOM_FIELD (Bottom field shown asap) set XV_FRAME_TYPE to XV_HOLD (Nothing happens on screen but the next put() won't flip) goto LOOP Let me know, -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: ATI Mach64 feature requests
On Sun, 21 Oct 2001, Mike A. Harris wrote: I'm curious as to what features of the ATI Mach64 variants that people would like to see supported or supported better in XFree86 that are either not currently supported, or are supported poorly. The first things that come to mind are: 1) DRI support It's my understanding that Gareth at VA was/is working on this. I haven't had a chance to look at that branch in the DRI CVS to see what kind of shape it's in. 2) Xvideo support, video in/out, TV tuner, etc.. I'm working on integrating Vladimir's patch for this. I'm reworking it so that much of it can also be used by other drivers. 3) ? 3) Finish off the remaining XAA primitives (including RENDER); 4) Merge in (from XF86_Mach64) 8bpp support for DAC found on the older GX/CX based adapters. There's also a few more minor things that I mention in README.ati. 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
[Xpert]Re: Troubles: Trident Cyber 9525/DVD
Hello, my notebook (Trident Cypher 9525/DVD, Kernel 2.2.19, X 4.1.0) sometimes have troubles during wake up procedure after suspend mode. Here some lines from the log-file which reveal one successful and one non successful trial: ... I am certainly no expert, but recompiling X from the CVS head has fixed virtually all of my X problems on my Trident9525/DVD laptop. Suspend/resume works again (mine wasn't working at all with 4.1.0), and Xv is nearly flawless for the first time ever. Good luck. .Geoff - Protect yourself from spam, use http://sneakemail.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Troubles: Trident Cyber 9525/DVD
Hello, my notebook (Trident Cypher 9525/DVD, Kernel 2.2.19, X 4.1.0) sometimes have troubles during wake up procedure after suspend mode. Here some lines from the log-file which reveal one successful and one non successful trial: ... I am certainly no expert, but recompiling X from the CVS head has fixed virtually all of my X problems on my Trident9525/DVD laptop. Suspend/resume works again (mine wasn't working at all with 4.1.0), and Xv is nearly flawless for the first time ever. Good luck. .Geoff - Protect yourself from spam, use http://sneakemail.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Troubles: Trident Cyber 9525/DVD
Hello, my notebook (Trident Cypher 9525/DVD, Kernel 2.2.19, X 4.1.0) sometimes have troubles during wake up procedure after suspend mode. Here some lines from the log-file which reveal one successful and one non successful trial: ... I am certainly no expert, but recompiling X from the CVS head has fixed virtually all of my X problems on my Trident9525/DVD laptop. Suspend/resume works again (mine wasn't working at all with 4.1.0), and Xv is nearly flawless for the first time ever. Good luck. .Geoff - Protect yourself from spam, use http://sneakemail.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]White Box Cusor
I am running Debian woody. First time Debian user, Linux user for a few years, now. My problem is with XFree86 4.1.0-7. After reconfiguring, reinstalling, recreating XF86Config-4, and adding Option SWCursor to my XF86Config-4 file, I cannot get rid of this white box for a cursor. Which sort of works, btw. Any ideas??? Card: Matrox MGA G200 (rev 3) Mouse: IMPS/2 Excerpt from XF86Config-4: = Section Module Loadddc LoadGLcore Loaddbe Loaddri Loadextmod Loadglx Loadpex5 Loadrecord Loadxie Loadbitmap Loadfreetype Loadspeedo Loadtype1 Loadvbe Loadint10E EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol ImPS/2 Option ZAxisMapping 4 5 EndSection Section Device Identifier Matrox G200 Driver mga Option UseFBDev true VideoRam8192 Option SWCursor EndSection Section Monitor Identifier Digital PCXAV-YZ HorizSync 30-60 VertRefresh 50-75 Option DPMS EndSection Section Screen Identifier Default Screen Device Matrox G200 Monitor Digital PCXAV-YZ DefaultDepth16 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
Duuudes... :) I think Matt's idea is AWESOME.. Absolutely gorgeous. Makes me almost cry. I don't see how that is different that just doing two XvShmPutImage's now and doubling the pitch and vertical scaling. Slight difference in that the client can't bias the top down a quarter pixel and bottom upward by a quarter pixels so they line up. And XvImages don't have a pitch to double. It's implied from the width just as XImages are. Yes that's the problem (although the pitch thing is avoided by setting up the image as a (width*2 x height/2) map and using the src offsets). I have a different idea that might work out better. Define these four things: XV_TOP_FIELD 0x1 XV_BOTTOM_FIELD 0x2 XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) XV_HOLD 0x4 Hmmm. That would probably work OK. I kindof like HOLD as 0x0 though (ie, no fields displaying and it makes the min-max 0-3 instead of 1-4). Yeah I think this idea is awesome. This probably also helps with 3:2 pulldown and the field repeat. No, I don't think it helps here. You never, ever want to perform 3:2 pulldown on a progressive display. If your monitor refresh is 59.94hz and you're providing 24fps content you still are better off showing the first full frame for 3 refreshes and then the next full frame for 2. If you're using Xv as an API for TV output, you've got worse problems, since you need accurate timing information (and TV norm and stuff) from the output card to know what's going on anyways. Something like the v4l2 TV output API may be better suited for this. If you're doubling output to both a TV and an Xv window (ugh!) then you should build progressive frames and display them on the monitor and let the TV output grab fields as necessary. We can't do better then that. :( What XV_HOLD would really help with though is still images, such as when a video player is paused or when it's sitting in a menu or FBI warning (which is encoded on the DVD as a single I-frame). However: Note that this introduces some slight uncertainty in the display since the overlay might not correspond to the window location when it comes time to actually display. But that's not going to be a big deal since the times are short and you get a delay now anyhow due to the overlay not going into effect until the retrace on most hardware. It introduces a larger lag between overlay and image when moving windows which isn't going to be a big deal. You can't do this for blitted video though. The cliplist is stale by the time you display. Not a problem though since blitted video are merely fallbacks. So, this breaks when we're paused or showing a still and you move the image around. Ugh. Are you sure this can't be handled in the hardware without the client having to do another put? Or do you expect the client to re-put whenever it moves (which it has to now anyways)? This has the benefit of getting rid of the unknown delay between the XvShmPutImage and the overlay flip since they are now separated (as they are in XvMC) plus you can display just top or just bottom. Matt you're awesome. The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means that apps using Xv without knowledge of this will just get a flip when they do an XvShmPutImage. Matt you rock my world. Just reset this back to 0x3 when any client releases the port. :) -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
