Re: [Xpert]S3 Trio64V+ ( 764/765 ) and Matrox G200 AGP 2X
Ani Joshi wrote: Can you post your /var/log/XFree86.0.log? There are some Trio64's out there which claim to be V+'s but are just regular Trio64's. Have you tried the s3 driver and it fails on your board? Okey , there is my xfree log attached to this message. I don't think this is a false Trio64V+ as i can read on the card the 765 chip code. The strange thing is that the xfree log saw it as Trio32/64. I've tried the s3 drivers with xfree 4.1 and i had no success. To speak true i had two(2) trio64v+ cards. With the first one i tried the s3 drivers in xf4.1 with no success and since then it doesn't work properly in vesa mode The screen go blank every time the CPU get busy ( It's a very strange behaviour ). With this second one i do not made any proof with s3 drivers ( until i know that 764/765 are supported) as i'm afraid to loose the possibility of use it with vesa drivers. Ah to get things more strange is that the broken trio works perfectly under windows9x . It's only under vesaxfree that it cause problems! Pheraps tha card has reported a bios damage and win9x do not use the card bios ( programming the graphics chip directly.. ) ? Cheers , Ritchard P.S. I've sent 1day ago the same message with the log not zipped and that message was blocked waiting for moderator. Now that message can be deleted as i send now the same message within 40kb limit. XFree86.0.log.gz Description: application/gzip
Re: [Xpert]Resize and Rotate extension progress report
On Thu, 19 Sep 2002, Keith Packard wrote: A question has arisen recently and we're hoping for some outside comments, given the passage of time and somewhat unanticipated advances in modern toolkits. The idea was to make sure that existing application would still be usable while the screen depth was switched -- emulating the desired visual with the hardware would leave those legacy applications running in an emulated visual while the smart applications reconfigured themselves to use one of the currently accelerated visuals. Given that there is no sample implementation of this capability, and that at least Jim and I aren't going to manage to produce one in the immediate future, the question is should we eliminate this part of the RandR specification so that the extension as a whole can demonstrate a complete sample implementation and become a useful standard part of XFree86? Eliminating this feature from RandR would mean that applications migrating from one X screen to another would need to be able to adapt to the available visuals, rather than anticipating that whatever visual currently in use would be available in the target server. As both Gtk+ 2 and Qt provide very abstract rendering interfaces for applications, (and GTK 2.2 supports moving between screens even between dissimilar X servers) this is not a burden for migrating applications written to either of these two toolkits, reducing the urgency of this part of the extension. The burden would fall solely on legacy toolkit applications which want to add migration capabilities (and the number of legacy toolkit applications continue to decline). ls -l /usr/lib/libgtk-1.2.so.0.9.1 /usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3* /usr/X11R6/lib/libXt.so.6.0 /usr/X11R6/lib/libX11.so.6.2 -rwxr-xr-x1 root root 1410465 Apr 18 02:18 /usr/lib/libgtk-1.2.so.0.9.1* -rwxr-xr-x1 root root 7644546 Apr 17 00:06 /usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3* -rwxr-xr-x1 root root 874476 Apr 19 04:12 /usr/X11R6/lib/libX11.so.6.2* -rwxr-xr-x1 root root 306040 Apr 19 04:12 /usr/X11R6/lib/libXt.so.6.0* and I thought Keith was worried about the size of Xt ! I'd like to be able to move an app from my palmtop to the living-room screen or video wall. I think it will a while before palmtops have memory/storage to be able to use Qt. Legacy apps may be in decline, but I think they have plenty of life left. Are we really asking that apps such as xdvi and ghostscipt be ported to Gtk+/Qt ? The other limitation would be that there would be no good way to share typical PC hardware between pseudo color and true color applications. Emulating pseuedo color operations on true color screens remains impractical. Environments left with legacy pseudo-color dependent apps would continue to run X servers in pseudo color mode without access to reasonable true color visuals. We could still perform this emulation in the server, but RandR provided the means to switch acceleration modes so that a large pseudo color app could get reasonable performance while wrecking the display of any simultaneously displayed true color apps. Although 8+24 overlay hardware support is very limited, PC hardware support for DirectColor isn't uncommon. I take it you intend to emulate PsuedoColor when DirectColor is available ? (Color-map flashing can be annoying, so I wouldn't object to a server flag which had to be set to enable PsuedoColor emulation.) However, without some interest in the community for this feature along with a reasonable commitment to helping with the implementation, it seems more important to get the subset of the specification known to work deployed widely rather than wait an indeterminant time for this final piece of the original design to be completed. Please comment if you have an opinion. Rotate and Resize doesn't imply Redepth, so I can't really object, but my interest in RandR has always been in the possibility of running legacy 8 bit apps on a 24 bit screen. I'm prepared to put some effort into a PseudoColor emulation, but my skills are such that I wouldn't be able to do it without pointers to get me started, and assistance when I get stuck, from someone like Keith or Jim. In practical terms, you are right, we should deploy the working subset rather than wait. -- 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]Issues with switching from DGA2 to window mode / XFree86 4.2.0
hi, Are there any issues which must be considered when switching back from DGA2 to normal (window-)mode under XFree86 4.2.0? I ask because I run into the following problems: - It happens when switching back from DGA2 that the state of the alt key remains afterward, which makes X unusable, as all key- and mouse events are processed with the alt-key flag set (although the key isn't pressed anymore). Usually window managers do their window-action magic, when the alt key is pressed. Usage is no further possible. Switching forth and back to DGA2 is bound to a combination with Alt and another key (Alt-d). I don't do any magic like Grabbing keyboard or Pointer. - Switching from DGA2 to window mode sometimes results in (client-)segfault in function XFilterEvent(...). This happens especially when XDGASetMode is issued within a (keyboard-)callback function. The callback is installed during window-mode with GTK+ primitives. XFilterEvent() is called from the GTK+/GDK libraries. The client is a Gnome/GTK+ (Gnome-1.4, GTK+ 1.2.9) application. I use: XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 [...] Build Operating System: Linux 2.4.9-13smp i686 [ELF] [...] (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Iiyama A901AT (**) | |--Device Matrox MGA 2064W which is a Matrox Millenium II with 4mb RAM. Linux-2.4.19 on a severly upgraded RedHat 7.0. The application is a versatile commodore emulator (Vice) featuring some basic gnome support and (on explicit request at compilation time with --enable-fullscreen) DGA2 support for smooth scroll animations by double buffering the emulation video rendering. Refer to version 1.10 under http://viceteam.bei.t-online.de. I digged through the xpert archives and found one maybe related posting: From [EMAIL PROTECTED] Tue Jun 11 13:31:43 2002 From: [EMAIL PROTECTED] (Egbert Eich) Date: Tue, 11 Jun 2002 14:31:43 +0200 (MEST) Subject: [Xpert]DGA keyboard state vs. Xkb Message-ID: [EMAIL PROTECTED] There is a long standing issue with DGA and xkb: When handling the keyboard from inside DGA it tries to keep the core keyboard state in sync. This is sufficient if no xkb extension is active. If the xkb extension is active however its internal state can get out of sync with unpredictable results if the core state has changed between start and exit of DGA mode. I worked around this by simply not updating the core state while inside of DGA if the xkb extension is active. Is there any deeper reason why DGA keeps the core keyboard state up to date or is this rather cosmetic? Egbert. Could this topic be related? Is this fixed in XFree86 4.2.1? A short test with XFree86-4.2.1 shows no real improvement regarding this problem. Big thanx in advance! I'm quite clueless how to cope with that problems. The application in DGA2 mode is quite useless when those instabilities remain. However, the smooth animations are worth investigating the issues further. bye, martin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon clone mode bug(s) + fix
Another idea: Currently, DisplayType (and CloneType) is an enum. How about making them bitfields? Doing so would make it possible to have more than one physical display connected to a CRT controller. This is at least possible in combinations something + CRT, but might even be possible with 3 devices (if I found a clock circuits settings for such setup). I don't mean cloning here, of course. Another thing: wouldn't it be better to drop Clone* and just use a primary/secondary display, possibly using common frame buffer when cloning? It would greatly simplify the code. I don't know XFree86 internals much, so I don't know if it would be easier. -- Krzysztof Halasa Network Administrator ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
ACA == Andrew C Aitchison Dr writes: ACA and I thought Keith was worried about the size of Xt ! I'd like ACA to be able to move an app from my palmtop to the living-room ACA screen or video wall. I think it will a while before palmtops ACA have memory/storage to be able to use Qt. Several already do, as there is an embedded version. (See, for instance, the new Zaurus.) QT is much more than just a widget set, though; it provides a platform-independent encapsulation of various OS features. ACA Are we really asking that apps such as xdvi and ghostscipt be ACA ported to Gtk+/Qt ? They already have been. - J ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]dual head with radeon ve 32mb ddr
On Fre, 2002-09-20 at 15:00, Geoffrey wrote: I've played around with trying to get my dual head hardware working, ATI Radeon VE with vga and digital out. I've tried all kinds of configurations to no avail. The best I get is a mirrored image on both monitors. I'm including the entries below I noted from a previous poster because my card is an AGP card, but the entry below is the first I've seen that contained a reference to a AGP busid. Might this be my problem? A couple of questions regarding this as well. lspci shows: 01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5159 for my card, which would seem to identify it as agp. Question is, should I be using 01:00:0 for both of my entries? Yes, and you need Screen directives in both device sections. And is that format correct? Looks good to me. -- 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]TV Out - Recommendations?
Hi all, I am putting together a set top box running linux for movies / web usage and would like to hear what TV Out cards you have seen best results from under Linux. I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) Many thanks, Mike ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TV Out - Recommendations?
Am Samstag, 21. September 2002 21:05 schrieben Sie: Hi all, I am putting together a set top box running linux for movies / web usage and would like to hear what TV Out cards you have seen best results from under Linux. I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) Well take a search engine and search for vgatv and linux and you will get a set of modelines and schematics to use any VGA-card for use with TVs. The quality is a _lot_ better than anything you get with normal TV-outs on cards. You will not be able to get a completely standard signal, but it's OK, and the quality is great. Servus Casandro Many thanks, Mike ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Warning! (this is no commercial ad) This e-mail probably will be read by secret services. Therefore please get pgp or gnupg and send me your public key so we e-mail encryptedly. http://www.gnupg.org/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TV Out - Recommendations?
On Sat, Sep 21, 2002 at 08:05:45PM +0100, Mike wrote: Hi all, Hello, I am putting together a set top box running linux for movies / web usage Join the (big) crowd. and would like to hear what TV Out cards you have seen best results from under Linux. Well, this is a contentious subject. The reason being is that most (all?) of the producers of TV-Out capable hardware are not providing (all of) the programming specs on how to do TV-Out with their cards. My conspiricy theory on this is that the producers of such hardware want also want to be able to write DVD-playing software, as a sell for their hardware. In order to (manufacture and) sell these things in the US, these producers are being hog-tied by the Copyright Consortium (spearheaded by such organizations as the MPAA, RIAA, etc.) into licensing the DVD-decrypto-magic. I suspect that such a license carries a clause that the hardware producer will not do anything to allow the easy copying of content and providing programming specs for these TV-Out capable cards does just that. I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) [ note the use of the word frame here is loose and not meant to differentiate between frames and fields ] It's called tearing. The reason is that the software/hardware is not waiting until the vsync to update what is being displayed on the television. If the software/hardware waits until a frame is fully displayed to the TV before changing it you do not see this effect. If it changes the frame while it is half-drawn to the TV, you end up getting part of one frame and part of the following frame. For the record, I am using a Matrox G400. They are hard to come by these days as they are no longer in production, and to the best of my knowlege, Matrox are not producing drivers, nor publishing specs for any of their newer cards. They are also a bit expensive to just display a video signal on a TV. b. -- Brian J. Murrell msg08972/pgp0.pgp Description: PGP signature
Re: [Xpert]TV Out - Recommendations?
On Sat, 21 Sep 2002, Mike wrote: Hi all, I am putting together a set top box running linux for movies / web usage and would like to hear what TV Out cards you have seen best results from under Linux. I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) This sounds like you are using TwinView and therefore, the video overlay can't be used, meaning the video is not synced ot the retrace. If you are not using TwinView and are only displaying on the TV, then the video overlay can be used and it should be synced to the retrace. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TV Out - Recommendations?
On Saturday 21 September 2002 03:05 pm, Mike wrote: I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) Have you tried using nvtv to set up the TV modes? It seems to have a lot of options. I use it myself on my nforce chipset. -- /* Chris Faherty [EMAIL PROTECTED] */ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TV Out - Recommendations?
lör 2002-09-21 klockan 21.15 skrev Christian Berger: Well take a search engine and search for vgatv and linux and you will get a set of modelines and schematics to use any VGA-card for use with TVs. The quality is a _lot_ better than anything you get with normal TV-outs on cards. You will not be able to get a completely standard signal, but it's OK, and the quality is great. It's not that simple, unfortunately. To obtain good quality, you'll need a graphics card that handles interlace on the VGA output. For NVidia cards, this feature seems to have been removed in newer models (some version of GeForce 2 and later). I don't think all Matrox cards support it either. Maybe other vendors still support it. Another problem with Nvidia cards is that acceleration stuff like XVideo doesn't work with interlace. This might not be a huge problem with a fast cpu, except that those cards that do support interlace properly (like the TNT) are old which means video transfers are slow. Fredrik ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Dual-head Geforce2, Radeon all-in-wonder 7500 not going.
Hello, I've not gotten a response before from this list and I kind of need this to do some work so I'm offering a $10 check to the first person who helps me get this working right. I have a Athlon XP 1800+/Asus RedHat 7.3 system with a PCI GeForce2 MX 200 card and a AGP Radeon 7500 all in wonder (has all the TV tuner stuff so will only do one head, unlike the regular Radeon 7500) card that I'm using to drive two Compaq S700 monitors. I have set the AGP card in the CMOS as the primary graphic adapter. I think I have things right in my XF86Config file (Xinerama on, etc), but can't get a spark out of the monitor connected to the PCI GeForce2. Works with Windows 2000. Thanks, Here is my XF86Config file: # File generated by anaconda. # ** # Refer to the XF86Config(4/5) man page for details about the format of # this file. # ** # ** # Files section. This allows default font and rgb paths to be set # ** Section Files # The location of the RGB database. Note, this is the name of the # file minus the extension (like .txt or .db). There is normally # no need to change the default. RgbPath/usr/X11R6/lib/X11/rgb # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. FontPath unix/:7100 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 Option Xinerama on EndSection # Pointer section # ** Section Pointer ProtocolIMPS/2 Device /dev/psaux #For wheel support - can not be used with Emulate3Buttons # #ZAxisMapping 4 5 # When using XQUEUE, comment out the above two lines, and uncomment # the following line. #ProtocolXqueue # Baudrate and SampleRate are only for some Logitech mice #BaudRate9600 #SampleRate150 # Emulate3Buttons is an option for 2-button Microsoft mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) # Emulate3Buttons Emulate3Timeout50 # ChordMiddle is an option for some 3-button Logitech mice #ChordMiddle EndSection # ** # Keyboard section # ** Section Keyboard ProtocolStandard AutoRepeat500 5 # when using XQUEUE, comment out the above line, and uncomment the # following line # Protocol Xqueue # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients # ServerNumLock # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Xleds 1 2 3 # To set the LeftAlt to Meta, RightAlt key to ModeShift, # RightCtl key to Compose, and ScrollLock key to ModeLock: LeftAlt Meta RightAltMeta ScrollLock Compose RightCtlControl # To disable the XKEYBOARD extension, uncomment XkbDisable. #XkbDisable # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: #XkbModelpc102 # If you have a US Microsoft Natural keyboard, you can use: #XkbModelmicrosoft # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: #XkbLayout de # or: #XkbLayout de #XkbVariant nodeadkeys # # If you'd like to switch the positions of your capslock and # control keys, use: #XkbOptions ctrl:swapcaps # # If you'd like to disable the capslock key, use: #XkbOptions ctrl:nocaps XkbRulesxfree86 XkbModelmicrosoft XkbLayout us XkbVariant basic #XkbOptions EndSection # ** # Monitor section # ** # Any number of
Re: [Xpert]Dual-head Geforce2, Radeon all-in-wonder 7500 not going.
On Sat, 21 Sep 2002, Ignacio Valdes wrote: Hello, I've not gotten a response before from this list and I kind of need this to do some work so I'm offering a $10 check to the first person who helps me get this working right. I have a Athlon XP 1800+/Asus RedHat 7.3 system with a PCI GeForce2 MX 200 card and a AGP Radeon 7500 all in wonder (has all the TV tuner stuff so will only do one head, unlike the regular Radeon 7500) card that I'm using to drive two Compaq S700 monitors. I have set the AGP card in the CMOS as the primary graphic adapter. I think I have things right in my XF86Config file (Xinerama on, etc), but can't get a spark out of the monitor connected to the PCI GeForce2. Works with Windows 2000. Thanks, Here is my XF86Config file: That's not an XFree86 4.x config file. What's your /var/log/XFree86.0.log say? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]_Screen struct -- internal code question
Where is the actual framebuffer for a screen stored? Shouldn't it be in a PixmapPtr's devPrivates or so? The basic problem I'm having is that none of the members of the screen struct, point to anything like a framebuffer. Where is the actual framebuffer to a screen stored? Thanks, Josie Imlay http://josie.atypedigital.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]_Screen struct -- internal code question
On Sat, 21 Sep 2002, J. Imlay wrote: Where is the actual framebuffer for a screen stored? Shouldn't it be in a PixmapPtr's devPrivates or so? The basic problem I'm having is that none of the members of the screen struct, point to anything like a framebuffer. Where is the actual framebuffer to a screen stored? The ScreenRec is a device independent structure, and as such holds no such information. Anything having to do with actually buffers are in the DDX. It doesn't really make sense to refer to *the* framebuffer of a screen, because that is a device specific detail that isn't even accurate for some of the devices that XFree86 supports. When overlays are used, the screen may be implemented as multiple buffers - one for each layer. XFree86 does have a pScreen-GetScreenPixmap which will return a Pixmap of the root window. If fb is your underlying framebuffer this will have a devPrivate and devKind indicating the raw pointer and stride of the root window, like a normal pixmap would have. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
