[Xpert]Re: [GATOS]How are different ATI drivers related ?
On Fri, Nov 22, 2002 at 02:34:28PM +0100, David Balazic wrote: > Hi! > > As a future ATI Radeon 8500 owner :-) I wonder about the different > available drivers : > > - xfree86 Default opensource driver version targetted for basic use. > - dri They concentrate on enhancing 3d funcionality. > - gatos They (we ) concentrate on enhancing multimedia functionality. > - ati.com They do whatever they want. > How are they related ? Between xf86, dri and gatos code is often merged, so that enhancements from dri and gatos find their way to main xf86 eventually. > Is there any overlap in functionality/features ? Code ? Yes, most of xf86/dri/gatos code is shared, but dri/gatos often offer more funcionality. > How about ATI.com ? Binary only ? AFAIK yes. > david balazic Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. msg11313/pgp0.pgp Description: PGP signature
Re: [Xpert]ATI Xpert128 + Quake2 on Linux = CRASH
On Mon, Sep 16, 2002 at 05:52:26PM -0500, Scott A. Conway wrote: > Hi, I was wondering if there is anyone else out there who has the same > problem I have with my ATI Xpert128 and Quake2 in Linux. No matter what > I do, whenever I start this program, it begins to load, then the screen > goes into DPMS shutdown, and I am forced to do a hard reset > (Ctrl-Alt-Del does not work) just to get the system working again. So, > WTF is goin on here? Try putting Option "XaaNoPixmapCache" into device section of XF86Config Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The dark ages were caused by the Y1K problem. msg08862/pgp0.pgp Description: PGP signature
Re: [Xpert]Re: improved xv refresh bug patch
On Wed, Aug 14, 2002 at 11:20:39PM -0400, Brian T. Schellenberger wrote: > Yes again . . . the mailer wrapped that one. The attachment should work. Hmm, could it be that this is causing the idiotic CPU load while using Xv*PutImage on my r128 that started about last November and I've been complaining all the time and noone knew how to solve? However, in my local copy of XF86cvs from about a month ago, I can't find any file named "xv.c" and grepping the patters from your patch didn't provide any results either, so I can't test it. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Press every key to continue. msg08323/pgp0.pgp Description: PGP signature
Re: [Xpert]Re: Xpert]Re: [MPlayer-users] X hangs on Ati Rage128AIW
On Mon, Jul 29, 2002 at 09:21:02PM +0100, Gustavo Alberto Homem wrote: > That's true. Before mandrake 8.2 I also tried gatos drivers and they were > still crashing with bttv, so I guess that someon on mdk solved the problem > somehow. Btw, the driver I use is the default one installed by mandrake > 8.2 , I didn't have to look around for any other. This is odd. It used to freeze for me (because the 2d accel functions were turning off DMA), but this was already fixed last year already. Are you sure you have the latest: - DRI kernel modules - gatos drivers ? I have a ATI AIW 128 (non-pro), AND a separate capture card, 2 soundcards and a SCSI burner and can use it all simultaneously (Xv, OpenGL and other stuff). The only stability problem are some 3d functions and this is easily worked around by by using Option "XaaNoPixmapCache" The other problem is that Xv(Shm)PutImage eats too much CPU, but this doesn't cause any instability. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. msg08098/pgp0.pgp Description: PGP signature
Re: [Xpert]Re: [MPlayer-users] X hangs on Ati Rage128AIW
On Sun, Jul 28, 2002 at 10:57:03PM +0200, Arkadiusz Miskiewicz wrote: > exactly the same problem. When DRM module is loaded (in my case > DRM from http://www.xfree86.org/~alanh/linux-drm-4.2.0-kernelsource.tar.gz > > Kernel: 2.4.18-3(compiled with option i need) > 2.4.18-5 from PLD here. > > X: XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) (with ati.2 > > binaries from gatos.sourceforge.net) > XFree 4.2.0 (tried both - xfree original and gatos ati drivers, also > treid different DRM sources - unfortunately my xfree still hangs). > Now I'm going to try cvs version of XFree 4.3.0. The problem is most probably old driver where dri and xf86 don't play well together and one turns off DMA while the second one needs it. Upgrade to: - Latest DRI, e.g. from DRI-CVS - Latest ati.2 binary from gatos.sf.net XF86 4.2.0 and RedHat 7.2 is ok, no need to upgrade. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? msg08066/pgp0.pgp Description: PGP signature
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, Jul 15, 2002 at 01:11:17AM +0200, Lukas Molzberger wrote: > Hello, Hi. > in recent years many people were talking about Linux on the desktop. > However, before there is any real chance that this could happen a few > fundamential problems in XFree must be solved. These are: Looks like a nice flamewar :-) > 1. XFree is far too slow. It is not. During the last couple of years I have been simply astonished how it improves. Perhaps you have an old XF86 version or badly supported driver or badly written app. With me it is VERY fast even on a PII or, in case you use thin clients even a PI. What you need is a lot of RAM, and you need it regardles of OS. > 2. What is presented on the screen should always be consistent (i.e. no > flickering). (translation for those who don't understand) -> syncing certain redraws to vertical refresh. This is in most cases solved by simply using a higher refresh rate. Having the ability to monitor vertical refresh is a neat thing e.g. for watching movies (actually a necessary one for high quality), but this doesn't necessarily have to do with X: the kernel must provide it first. > (3. It should be possible to configure XFree over a dialog that is intergrated > in Gnome and Kde.) This isn't a problem of XF86 but of KDE/Gnome. Thought it would be neat if XF86 provided ways to change virtual resolution, depth and refresh rate on the fly, as far as I know it can't do this currently. > I'm sorry to say that and I really don't want to offend any people. But > I've hardly seen any progress regarding these problems during the last two > years and I don't see any way how this could change in the next two years. Oh? I have seen VERY MUCH happen in this area in the last 2 years (4.0 is a MAJOR improvement, so is Xv, DRI, RENDER, ...). Perhaps you weren't following the development that closely. > Cheers > Lukas Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- It is easier to fix Unix than to live with NT. msg07674/pgp0.pgp Description: PGP signature
Re: [Xpert]XWindows in MSWindows
On Sun, Jul 07, 2002 at 09:09:09AM +0100, Dr Andrew C Aitchison wrote: > On Thu, 4 Jul 2002, RamaSubramanian KrishnaMurthi wrote: > > Is there any application like telnet that brings the > > XWindows in the Microsoft windows from the remote > > computer. If you find any send some info about it. > However you may wish to consider VNC > http://www.uk.research.att.com/vnc/ I'd like to mention krfb, which is a vnc server for X that can "overtake" a current session, like original vnc does on windows. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- "Where do you want to go to die?" msg07486/pgp0.pgp Description: PGP signature
[Xpert]r128, DRI and XaaNoPixmapCache
Hi! I just found out that unless you use XaaNoPixmapCache, dri on r128 freezes (== complete system lockup) pretty often. I use yesterday's XF86 CVS. Well, I thought it might be a good idea to write this on the webpage or into docs with BIG letters, because otherwise gaming is pretty unusable if it freezes every hour or so. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg07288/pgp0.pgp Description: PGP signature
Re: [Xpert]Radeon TVOut
On Fri, May 31, 2002 at 06:46:30PM +0200, Gniazdowski Mariusz wrote: > Hi, hi > does XFree support TVOut in ATI Radeon ? Partially, inside devel branch of gatos. Look at gatos.sf.net and read the docs, and perhaps check the [EMAIL PROTECTED] archives. > Mariusz Gniazdowski Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Disc space - The final frontier. msg06639/pgp0.pgp Description: PGP signature
Re: [Xpert]Question about ATI Rage
On Fri, Apr 26, 2002 at 02:13:18PM +0100, Paul Robertson wrote: > We use ATI Rage 128 and Rage XL cards in a system where we make heavy use of > Xv to render images in YUV colour space. > I have been asked the question > "Does the graphics card support master mode DMA for video overlay?" > Can someone answer it for me? The card sure does, the point is if the driver does. Recent r128 driver does this but you need working DRI. More precisely when calling XvShmPutImage and XvPutImage, r128 driver will try to make use of DMA if available and working. RageXL is mach64 AFAIK and DRI for it is under development, DMA being HEAVY in development. When it's working, I'm sure someone will adapt the r128 code for mach64. > Thanks, > -- > Paul Robertson Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- It is easier to fix Unix than to live with NT. msg05771/pgp0.pgp Description: PGP signature
Re: [Xpert]XFree 4.2.0 Problem with Cut And Paste / German Umlauts
On Tue, Apr 23, 2002 at 12:36:03PM +0200, Marc-Christian Petersen wrote: > Hi there, hi > i've upgraded to xfree 4.2.0 yesterdays evening and have some problems, or, > no, only one problem. I cannot Cut and Paste between any application :-((( > Attached is my XF86Config-4. Dunno, could it be the 3rd button isn't configured properly? > In some apps i don't have german umlauts, but not in all. With XFree 4.1 it > works great. Try "nodeadkeys" variant, I also have lots of troubles without it :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- three saints: looser & lamer & hacker msg05703/pgp0.pgp Description: PGP signature
Re: [Xpert]Question About Bus mastering
On Tue, Apr 09, 2002 at 04:12:27PM -0600, [EMAIL PROTECTED] wrote: > Hi, hi > I would like to know whether XFree86 supports bus mastering option? If > yes then is there anyway I can switch off the bus mastering option? AFAIK this isn't done directly by XF86, but by projects like DRI. XF86 can use DRI to do busmastering. In that case you can turn it off by disabling DRI (i.e. not loading the module or commenting the appropriate line in XF86Config). BTW the only reason I imagine disabling busmastering is useful is if it causes freezes or corrupt video output. If this is the case, you should consider reporting it (e.g. here or to dri-devel). > regards, > Vikram Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Press every key to continue. msg05431/pgp0.pgp Description: PGP signature
Re: [Xpert]Direct 2D Access for Streaming Video
On Mon, Mar 25, 2002 at 09:08:08AM -0800, Shane Walton wrote: > Hello, hi > Could someone point me in the right direction to the ability to DMA a video > frame from shared memory to the graphics device? Is there a way to use > OpenGL along with DRI? There is just too much overhead involved to allow > the Xserver to handle a CPU based memory transfer. Any thoughts/comments > are appreciated. Thank you much. The BlitTexture function may be what you're looking for. > Regards, Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. msg05091/pgp0.pgp Description: PGP signature
Re: [Xpert]problem with ATI mach64 / xpert card
On Tue, Mar 19, 2002 at 03:21:47PM -0800, Will Yardley wrote: > both my original configuration (from 4.1.0, which worked fine) and any > other configuration i try (most of them derived from 'X -configure) > result in the screen being slanted to the right at the top of the > screen. i saw a similar problem recently in the archives but didn't > notice any resolution (and the shape of mine is a bit more crooked than > the example. There is one, turn off composite sync (just uncomment and set to off). This was apparently an unfortunate decision in 4.2.0 that has been reversed afterwards. > Option "composite_sync" "True"# [] Should be "False" or "Off". > #Option "composite_sync" # [] Here too. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Reboot America. msg04984/pgp0.pgp Description: PGP signature
Re: [Xpert]A rough sketch of what the screen looks like
On Mon, Mar 04, 2002 at 11:22:32AM +0100, Michel Dänzer wrote: > On Mon, 2002-03-04 at 02:42, Eric wrote: > > http://atlantis.phantasus.net/~spirilis/atidrv_glitch.png is a rough > > sketch of how the display is skewed... (drawn in GIMP) > Try Option "composite_sync" "off" in the device section. Hehe I actually had the same problem today :-). It seems like composite_sync defaults to on in 4.2.0 and off in 4.1.0 for mach64. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Better Artificial Inteligence than Natural Stupidity msg04651/pgp0.pgp Description: PGP signature
Re: [Xpert]A rough sketch of what the screen looks like
On Sun, Mar 03, 2002 at 08:42:30PM -0500, Eric wrote: > http://atlantis.phantasus.net/~spirilis/atidrv_glitch.png is a rough sketch of how >the display is skewed... (drawn in GIMP) My guess is that it's the monitor that can't cope with the frequency correctly. Try setting a different one. I don't think it's a software problem. Alternatively, you can try it on a different monitor, if you can reproduce the glitch. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- It's not a bug, it's tradition! msg04603/pgp0.pgp Description: PGP signature
Re: [Xpert]rehor@students.zcu.cz
On Tue, Jan 29, 2002 at 10:15:28AM +, Mike Heald wrote: > Hi, hi > The glitch I have is on logging out of X, gdm comes back up. > There are green lines at the top of the screen and the gdm window > is not redrawn properly. The 3-line patch I posted a couple of days ago MOSTLY fixes this. > Mike Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows. msg03697/pgp0.pgp Description: PGP signature
[Xpert]Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 08:15:29PM -0300, Davor Buvinic wrote: > Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI > drivers sources. No more messages in the kernel log like the following: > > [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 Yes this was exactly what it was intended to fix, and several similar errors as well. > But if I play a video and run glxgears X crashes. Option "UseCCEFor2D" didn't > appears to help... Hmm I just tried aviplay together with glxgears without crashing (though gears caused aviplay to crawl). What do the logs show? > - Davor Mit freundlichen Grüßen Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg03630/pgp0.pgp Description: PGP signature
[Xpert]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dänzer wrote:
> After digging around the code a bit, my current theory is that the
> indirect buffer is incorrectly reused after the start of a new server
> generation. The only difference I see in the radeon driver (which I
> assume doesn't have the same problem?) is in the LeaveServer() function,
> where it releases the indirect buffer. Can you try if that fixes the
> problem?
Yes this seems to have fixed it, here's the patch:
--- ati.2/r128_dri.cMon Dec 31 06:00:11 2001
+++ ati.2-shurdeek/r128_dri.c Sun Jan 27 20:50:19 2002
@@ -308,6 +308,9 @@
info->sc_bottom = INREG(R128_SC_BOTTOM);
info->aux_sc_cntl = INREG(R128_SC_BOTTOM);
}
+} else {
+ R128CCEFlushIndirect(pScrn);
+ R128CCEReleaseIndirect(pScrn);
}
}
Would please the responsible person in all projects (dri, xf86, gatos) apply it?
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
The product Microsoft sells isn't the software; it's comfort.
The product that Linux vendors usually sell is freedom.
msg03625/pgp0.pgp
Description: PGP signature
Re: [Xpert]r128 / dri / XFree 4.2.0 / crash
On Sun, Jan 27, 2002 at 01:13:54AM +0100, Mathieu Perrin wrote: > > Oh, doesn't syslog say anything BTW? > Nothing at all :/ In that case, try drm modules directly from the DRI project, those in XF86 are slightly different. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- funny thats the third time since ive been on IRC today that i seen the word "slave" and "microsoft" in the same sentence msg03598/pgp0.pgp Description: PGP signature
Re: [Xpert]r128 / dri / XFree 4.2.0 / crash
On Sun, Jan 27, 2002 at 12:01:50AM +0100, Mathieu Perrin wrote: > On Sat, 26 Jan 2002, Vladimir Dergachev wrote: > > Please try http://gatos.sf.net/ ati.2 binaries. > I already tryed these drivers ( experimental 6, ATI-4.2.0 and drm-kernel), > and I have the same problems Are you sure agpgart is loaded? my X also freeze often if only r128 (and no agpgart) is loaded. Oh, doesn't syslog say anything BTW? > Mathieu Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- There's no place like ~ msg03595/pgp0.pgp Description: PGP signature
Re: [Xpert]Unresolved symbols in r128_drv
On Sat, Jan 12, 2002 at 01:14:17AM +, Mike Heald wrote: > Hi, hi > I'm using the xc cvs from a few days ago, cannot get drm working on my > rage128 based card due to the following unresolved symbols... > drmFreeBufs > drmR128TextureBlit Yup, this is the ubercool DMACopyData stuff. Upgrade your dri. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows." msg03170/pgp0.pgp Description: PGP signature
Re: [Xpert]Source code of NVidia Drivers?!?
On Fri, Dec 28, 2001 at 05:25:40PM +0100, Tiammazzo wrote: > Will ever NVidia release register specs of geforce & riva??? Not anytime soon. The main cause is licensing of technologies, nvidia simply isn't allowed to give docs to most stuff. Second cause is advantages over competitors. Remember, information == money and if you reach a big enough market share, you have very few reasons to make the information that allowed this public. > If not, why Because we live in an imperfect world. Deal with it, code opensource stuff. I see gensig found a proper tagline as well :-) > Till when we'll have a non-functional framebuffer device and fbdev libraries > (like DirectFB, see www.directfb.org) will not be able to use > hw-acceleration?? Unless you live in USA, you still can reverse-engineer and do trial/error stuff. Yes, it sucks compared to even humble docs, but noone is preventing you from doing so. > The release of specs (like matrox and ati already did) would be welcome by > all the opensource comunity From what I know, Matrox doesn't publish 100% docs either, and ATI actually: - doesn't release docs to "community", only to registered developers that have to agree to a NDA. From practical point of view indeed anyone can have them with a little effort, but from "RMS Point of view" they are still proprietary, definitely not opensource or public domain. Please note this isn't supposed to be a negative remark, I'm only trying to correct the statements. A LOT of other drivers for linux / X are written this way, registered developers get docs under NDA and can write GPL/BSD/whatever code. - doesn't give ALL docs we'd like, mostly for the same reasons as Nvidia. tvout is undocumented on either matrox or ati because of macrovision, and the new radeon 8500 3d stuff isn't documented 100% (I assume because it is the first thing that was able to come near the consumer 3d market leader nvidia since a couple of years) > Hi all :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- - "The world we're living in lies always in darkness." - "That's why we're seeking the light." msg02773/pgp0.pgp Description: PGP signature
Re: [Xpert]questions about an ATI Rage Pro LT
On Fri, Dec 21, 2001 at 03:33:42AM +0200, Joseph Teichman wrote: > I noticed when I set up my Red Hat 7.2 box with an ATI Rage Pro LT card yup thats a mach64 card. > Also, how do I find out the various features of the different chipsets... if > I could get a hold of programming information about my card, I would be > happy to try to contribute to the XFree effort to get some accelerated stuff > in. Does ATI publish the information that would be necessary? I couldn't > find anything like that on their web site. You can register on the ati devrel page and then they'll give you access to a lot of docs. > Thanks, > Joseph Teichman Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- I believe the technical term is "Oops!" msg02648/pgp0.pgp Description: PGP signature
Re: [Xpert]ATI Radeon VE and SGI 1600sw with Multilink
On Thu, Dec 20, 2001 at 07:37:21PM -0500, Stuart Anderson wrote: > > > 1. DPMS doesn't work. I looked in the source and it seems that DPMS > > > only gets turned on if connected to a CRT. Why shouldn't this work for > > > a flatpanel? > > Why should it? ;) I think DPMS was conceived for CRTs so I wouldn't > > expect it to apply to flat panels naturally. > I had notice the same thing int he ATI driver. On my laptop, Windows can > completely shutdown the LCD screen, but under X, it doesn't. Well I have a mobility with mach64. dpms didnt work with 3.x and was screwed with 4.0.3 (like it claimed the backlight was on even if it was off) but with 4.1.0 it seems to work ok. Luckily my notebook has a little button that can be programmed to turn the backlight off and gets automatically pressed if you close notebook. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Dudes! May the Open Source be with you. msg02646/pgp0.pgp Description: PGP signature
Re: [Xpert]Tearing, with regard to viewing DVDs (Trident Ai1)
On Wed, Dec 19, 2001 at 11:58:34AM -0800, Billy Biggs wrote: > ObOnTopic: One way to test for tearing if you have a v4l card would be > to try out my TV deinterlacer, which will output at 59.94fps (or 50fps > for PAL). You'll see tearing pretty quick if your driver doesn't double > buffer: > http://www.dumbterm.net/graphics/tvtime/ ffmpeg can also deinterlace from v4l devices BTW (i.e. from an interlaced PAL you can get 25 fps non-interlaced video) Besides, it's SO easy to get high quality dvd rips so there really shouldn't be a problem finding usable material. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? msg02624/pgp0.pgp Description: PGP signature
Re: [Xpert]TV-Out capable cards..
On Wed, Dec 19, 2001 at 10:27:14AM -0500, John Clemens wrote: > Also if you don't mind compiling, I just noticed that TV-out on the 3Dfx > Voodoo3 3500TV is also supported, albeit in a roundabout way. You can > find those cards very cheap now. Actually the installation/configuration is pretty easy, you just need i2c module for something (look for lm_sensors project on freshmeat). But I must say the TV picture quality with voodoo3 3500TV is significantly worse than my r128 (not to mention the unusually big adapter and thick cable that comes with it). OTOH 3D is definitely faster with v3 than with r128, you'd need radeon to match 3D performance. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- I believe the technical term is "Oops!" msg02611/pgp0.pgp Description: PGP signature
Re: [Xpert]TV-Out capable cards..
On Wed, Dec 19, 2001 at 09:31:21AM -, Russell, David J wrote: > Sounds like the RADEON VE is supported :o) > ... but the TV out is not :o( Preliminary TVout support is in devel branch of gatos (gatos.sf.net). If you don't mind playing with compiling a little, it works nicely. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Dudes! May the Open Source be with you. msg02596/pgp0.pgp Description: PGP signature
Re: [Xpert]SiS630 Xv performance
On Tue, Dec 18, 2001 at 10:16:11PM +0100, Andre Werthmann wrote: > > Ok here are the numbers. ;) > > 1.) playing a dvd windowed with xine / Xv > %CPU > 1477 root 16 0 57884 24M 10968 R60,4 11,0 0:25 X > 1666 andre 10 0 21772 21M 10932 S 3,7 9,7 0:02 xine > 1669 andre 9 0 21772 21M 10932 S 1,9 9,7 0:00 xine > > 2.) playing a dvd windowed with xine / XShm > > 1710 andre 17 0 34836 34M 14796 R28,1 15,5 0:08 xine > 1477 root 9 0 61724 27M 14808 S 2,1 12,8 0:37 X > 1712 andre 10 0 34836 34M 14796 S 0,9 15,5 0:00 xine > > With Xv the XServer is eating up all the cpu time... Well then I guess it is a driver problem. It could also be exactly what I said (DMA), because the "%CPU" shown isn't lineary proportional, because of how it's measured (100Hz timer interrupt). I remember when I did calculations previously to adding DMA to r128, a 2fold increase in data amount caused 35fold increase in the number shown. (All who think about response, please note I'm explicitely talking about NUMBER SHOWN, not real CPU usage). May I suggest to try other dvd player (e.g. vlc, www.videolan.org), and write back how the numbers look like there. Vlc also has lower CPU consumption than xine btw, perhaps it'll help. Also, please try to do Xv fullscreen and run top over ssh from other machine. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Better Artificial Inteligence than Natural Stupidity msg02579/pgp0.pgp Description: PGP signature
Re: [Xpert]SiS630 Xv performance
On Tue, Dec 18, 2001 at 10:53:55AM -0800, Mark Vojkovich wrote: > > It is because the driver uses memcpy for transferring of the data. The > > correct way to solve this is to add dma support. In current cvs XF86 r128 > > does this so it can be used as a reference implementation. > That's silly. Plenty of other drivers do this without DMA and have large > performance increases over XShmPutImage - typically a factor of two savings > with scaling for free. In the worst case XvShmPutImage should be comparable > to XShmPutImage. Absense of DMA capability is not the problem. Ok, it indeed looks suspicious and the source of the problem is unclear. Perhaps the original poster might tell us WHAT PROCESS eats how much time in either (XShmPutImage/XvShmPutImage) cases? If it's like: (XShm) X - 20, player 10 (XvShm) X - 50, player 10 then most probably the X driver is fscked (it still can be player's fault though). If however it looks like (XShm) X - 20, player 10 (XvShm) X - 20, player 40 then it is definitely the player is guilty. Or it could be something else :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Where do you think you're going today? msg02575/pgp0.pgp Description: PGP signature
Re: [Xpert]SiS630 Xv performance
On Tue, Dec 18, 2001 at 03:07:29PM +0100, Andre Werthmann wrote: > I have a laptop with a SiS630 chipset and use XFree86 4.1 (sis driver with > the vesafb hack). > When I play a dvd in windowed mode (720x576) with xine and I use XVideo > the cpu(1.1Ghz P3) is utilized at 66% while playing with XShm the cpu is > utilized only at 31% ! > (the same with mplayer) > > This effect is the same at all colordepths (16bpp and 24bpp). > > I thought Xv should take the strain off the cpu a bit... > > > Anyone has an idea what may cause the problem ? It is because the driver uses memcpy for transferring of the data. The correct way to solve this is to add dma support. In current cvs XF86 r128 does this so it can be used as a reference implementation. > Thanks, > -Andre. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- rm -f /bin/laden msg02568/pgp0.pgp Description: PGP signature
Re: [Xpert]Font + antialiasing fsckes up certain characters
On Sun, Dec 16, 2001 at 10:36:51AM -0500, Owen Taylor wrote: > > To quote from the freetype CVS logs: > 2001-10-08 davidT > * /cvsroot/freetype2/src/psnames/psmodule.c, >/cvsroot/freetype2/src/psnames/pstables.h: > * src/psnames/pstables.h, src/psnames/psmodule.c, >src/tools/glnames.py: > fixed a bug in 'glnames.py' that prevented it from generating correct > glyph names table. This resulted in the unavailability of certain >glyphs > like "Cacute", "cacute" and "lslash" in Unicode charmaps, even if >these > were present in the font (causing problems for Polish users). > You might want to try upgrading to FreeType 2.0.5 - it most likely > contains this fix. Yes, I confirm this, I built a rpm of 2.0.5 and upgraded and the problem is fixed for good. I don't use cacute/lslash, that's Polish-specific, but Slovak and Czech freetype users will be happy as well because ccaret suffered from the same problem. Thnx! > Regards, > Owen Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Press every key to continue. msg02518/pgp0.pgp Description: PGP signature
(quick fix) [Xpert]Font + antialiasing fsckes up certain characters
On Sun, Dec 16, 2001 at 12:25:18PM +0200, Richard ?epas wrote: > >I have also noticed this effect (try konsole for example). I don't use >latin2 but utf-8. It happens with Type1 > >fonts from XFree 4.1 like Courier or Lucidux*. It doesn't happen with TTF. > > > ... and it shows with xterm as well, so it is probably XFree bug: > xterm -fa 'Courier New' -fs 14 > is OK, but this: > xterm -fa LuciduxMono -fs 14 > shows space instead Ä. You can cut&paste it, i.e. character code is OK, but it >just shows as blank. Ok I tried this and it partially is correct for me as well. It DOESN'T happen with truetype fonts. OTOH, I am unable to reproduce with xterm, so it really seems to be a QT bug. The "fscked" font seems to be helvetica: when kde apps use it, c+caret is missing, but when I use arial from M$s truetype fonts instead, it is ok. But I did a xlsfonts|grep -i helvetica|grep iso8859-2| blahblah and started xterm with all of the matching fonts. They are indeed antialiased, but none of them were fscked. Also for some strage reason I can't tell konqueror to use arial instead of helvetica. In the html source on the pages it sez something like "font face arial, verdana, helvetica", which konqueror interprets as "prefer helvetica", even if I rearrange order of font directories. The fix I was able to put together, is to do cd /usr/share/fonts/default/Type1/ rm -f n01* fonts.dir;mkfontdir restart xfs, restart X voila, it's fixed. So it seems that qt and urw fonts don't mix well. So what to do now, write to trolltech? It's fixed for me so I don't care anymore :-) > âť RiÄardas Äepas âş Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows. msg02517/pgp0.pgp Description: PGP signature
Re: [Xpert]Font + antialiasing fsckes up certain characters
On Sat, Dec 15, 2001 at 02:01:51PM -0800, Keith Packard wrote: > Around 20 o'clock on Dec 15, Peter Surda wrote: > > I have a question about fonts. When using antialiased fonts, the character > > c+caret (that's what I think it's called, it's used in several Slavic Central > > European languages and is of course in iso-8859-2) doesn't get displayed, > Anti-aliased fonts are always in Unicode; your application may not be > correct translating from the Latin-2 encoding to Unicode. You might give > this a try with a Qt application and see if it works right. Well, konqueror is using Qt, isn't it? So this is actually a Qt bug? I have no idea, that's why I'm asking... I have RH 7.2 with almost all updates (qt-2.3.1-5)... > Keith Packard XFree86 Core TeamCompaq Cambridge Research Lab Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. msg02506/pgp0.pgp Description: PGP signature
[Xpert]Font + antialiasing fsckes up certain characters
Hi guys! I have a question about fonts. When using antialiased fonts, the character c+caret (that's what I think it's called, it's used in several Slavic Central European languages and is of course in iso-8859-2) doesn't get displayed, the place where it should be is empty. This isn't font-specific (happens with everything I tried including truetype fonts) or distribution-specific (both mandrake 8.0 and RH 7.2 "vulnerable" :-)) Turning off antialiasing fixes it. As far as I know, this one character, both in lowercase and uppercase, is the only one experiencing this. I made a 11kB big screenshot of the situation, you can see it at http://panorama.sth.ac.at/font.png There are 2 rows displaying all the characters you need for Slovak, Czech and German language if you use ISO-8859-2 (i.e. it is the same text file, once in konqueror and once in konsole+less). Upper row is with antialiasing, lower without. You can clearly see that in the places where c+caret and C+caret is in the bottom row, it is missing in the top row. Any hints on what is causing this and how to fix it? It's been like this at least for half a year. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Don't drink and su. msg02489/pgp0.pgp Description: PGP signature
Re: [Xpert]dri trouble
On Sun, Dec 09, 2001 at 04:07:27AM +0100, Michel Dänzer wrote: > On Sun, 2001-12-09 at 03:49, Peter Surda wrote: > > - there are minor display distortions (parts of screen remain black, basically > > the kde splash screen is completely fscked, but it sorts out later). > Does the R128BlockHandler() function of the driver you're using contain > a FLUSH_RING(); ? Yes it does. It could be possible that this bug is triggered by tvout int10, because it manifests itself as overwriting certain videoram parts with 0's. OTOH splash screen looks ok if I disable dri > > - when I do a chvt 1;chvt 7, X starts eating all the CPU time and 2d > > accelerated functions seize working (mouse can be moved but kde panel > > doesn't pop up). killall X doesn't work, killall -9 X does. When this bug > > feels like it should become especially mean to me, this killall -9 X causes > > a complete machine lockup. > In R128EnterVT(), try moving the R128ModeInit() and R128EngineInit() > calls before the code guarded by #ifdef XF86DRI. Yes, you were absolutely right, as always, this wasn't there and moving the lines fixed the bug for good. Syslog still complains CONTINUOSLY though, but I think that isn't so important now. > Those are fixes I made in DRI CVS some time ago, but at least the first > one is in XFree86 CVS now. I see. Volodya, pls commit the second one. In r128_driver.c, there is a R128EnterVT function, and you only have (as Michel says) move ModeInit and EngineInit (3 lines) before the #ifdef XF86DRI. Same goes for xf86 maintainers (Marc, Mike, Michel, whoever feels like doing it), pls commit in case it isn't there yet. Now I hope this was the last thing that prevented me from reaching normal uptimes. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". msg02300/pgp0.pgp Description: PGP signature
[Xpert]dri trouble
Hi ppl! I have come to the conclusion that there is a bug "somewhere" (TM). Using XF86 cvs from about 4 days ago, gatos cvs from the same time. Following happens with the r128.o I get in either xf86 cvs or dri cvs: - ten kernel: [drm:r128_cce_indirect] *ERROR* process 2635 using buffer owned by 0 - (X logs don't show anything) This is IMHO the reason why when using dri: - there are minor display distortions (parts of screen remain black, basically the kde splash screen is completely fscked, but it sorts out later). - when I do a chvt 1;chvt 7, X starts eating all the CPU time and 2d accelerated functions seize working (mouse can be moved but kde panel doesn't pop up). killall X doesn't work, killall -9 X does. When this bug feels like it should become especially mean to me, this killall -9 X causes a complete machine lockup. This also happens immediately after a fresh bootup when I haven't done anything yet. Volodya: whether km is loaded doesn't matter. These problems disappear when I comment dri in XF86Config. Card: ATI AIW 128 16M AGP (non-pro). Kernel 2.4.14. RH 7.1 with current patches. Hints (besides not using dri)? I finally want to get better uptimes than 3 days. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. msg02279/pgp0.pgp Description: PGP signature
Re: [Xpert]Tv out working for ATI mobility ?
On Fri, Dec 07, 2001 at 01:38:28PM +0100, JM Martin wrote: > Hi, hi > Does the TV out works now with ATI rage pro 8Momobility under Linux ? Last > year it was'nt working, does anyone use the tv out with ATi mobility ? There isn't working code yet, but I basically have a pretty good idea how to do it, but I'm busy with other stuff. I most probably will write it at some time. This process can be speeded up by sending me anime DVDs :-). > Thanks > Jean-Marie Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Intel: where Quality is job number 0.9998782345! msg02214/pgp0.pgp Description: PGP signature
Re: [Xpert]TVOut/Motion Video on ATI cards anytime soon?
On Wed, Dec 05, 2001 at 12:10:13PM -0800, Alex Deucher wrote: > What about iDCT and other XvMC goodies? Hmm I think unless you have a notebook (battery life) you don't need this for normal stuff, DVD playback now has low enough CPU usage. But anyway from what I know this is being worked on, or at least being thinked about working on :-) > Alex Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- To boldly go where I surely don't belong. msg02126/pgp0.pgp Description: PGP signature
Re: [Xpert]Radeon VE TV OUT
On Wed, Dec 05, 2001 at 10:05:47AM -0600, Korey O'Dell wrote: > Folks, hi > I have heard the latest CVS of X4.1 contains the necessary fixes to > enable tv out. Is this true? No. TVout is in devel branch of gatos, but it's pretty rough, it may not work with your card. > Also, have heard that using the "DMA-accelerated XvShmPutImage" helps > greatly with performance. Does the latest CVS 4.1 include this as well > for the Radeon VE? Well, I don't think you'll see such a great difference on radeon. It's mach64 and r128 that are vry slow in transferring data, the difference here can be up to 30%. I guess with radeon you'd get like 15%. > Any other tips/tricks to get tv out working? use the source or send me anime DVDs and I'll find some time to write it :-) > Many thanks > Korey Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. msg02111/pgp0.pgp Description: PGP signature
Re: [Xpert]TVOut/Motion Video on ATI cards anytime soon?
On Wed, Dec 05, 2001 at 05:41:25PM +0100, Thomas Gebhardt wrote: > Hi, hi > As far as I can remember (www.linuxvideo.org seems to be down or > unreachable from here), Server's being upgraded, downtimes may occur. > gatos allows to generate TV out, but does not deal with TV in? Am I right > here? My plan was to display (grap?) some video clips from the camcorder. that isn't correct, gatos tries to use all multimedia things on ATIs. Currently well working is video display and tv-in (aka XVideo extensions). There are experimental TVout patches and even a v4l module for kernel (capturing), which may or may not work on your card, and may freeze your machine. > Thanks anyway, Thomas Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg02110/pgp0.pgp Description: PGP signature
Re: [Xpert]TVOut/Motion Video on ATI cards anytime soon?
On Wed, Dec 05, 2001 at 02:20:21PM +0100, Thomas Gebhardt wrote: > Hi, hi > from README.ati: > > Support for the following will be added in a future release: > > o TVOut, i.e. the ability to use a television screen as a monitor. > > o Motion Video, i.e. displaying an asynchronous data stream (TV signal, > > DVD, etc.) in a window or full-screen. > can we expect to get this stuff included in any of the forthcoming > releases? (especially for my ATI Rage 128 Pro TV in/out card :-) I don't know what "Motion Video" is referring to, but you can certainly watch either TV singal or DVD full screen. TVOut support for r128 is in devel branch of gatos, but isn't near "normal user use" yet. I vaguely promised several times to write unified tvout ati support, but I'm busy with other stuff now, and since it works on my box already I'm not pushed to doing it. > Thanks, Thomas Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Secret hacker rule #11: hackers read manuals. msg02099/pgp0.pgp Description: PGP signature
Re: [Xpert]Tearing on overlay surfaces
On Mon, Dec 03, 2001 at 12:44:39PM -0800, Mark Vojkovich wrote: > On Mon, 3 Dec 2001, Peter Surda wrote: > > yet), which caused total machine lockup. Xine also causes lockup from >Those are bugs in the ATI drivers. thx for the praise. Michel was kind enough to explain to me why this is happening and is already supposed to be fixed in CVS, which I'm trying to checkout right now. > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Better Artificial Inteligence than Natural Stupidity msg02030/pgp0.pgp Description: PGP signature
Re: [Xpert] DMA lockup (Was: Tearing on overlay surfaces)
On Mon, Dec 03, 2001 at 01:18:29PM +0100, Michel Dänzer wrote: > > (I am a co-author of the DMA-enabled Xv*PutImage for r128 you mentioned) > > As you probably have detailed reports on how this DMA-enhanced Xv*PutImage > > works on nvidia, don't you have stability problems with certain players? I > > noticed that while I never had troubles with aviplay or mplayer, vlc was not > > properly programmed and one thread liked it a lot to kill a Xv*PutImage > > running in another thread (has likely been fixed already but I haven't checked > > yet), which caused total machine lockup. Xine also causes lockup from time to > > time. > If you're running 4.1, this is probably because the chip can hang when a > bus mastering operation is active while it's being reset in the course > of switching the CCE on or off. AHA! So I suppose then THIS is also the reason why km (experimental ATI capturing v4l module) doesn't mix with DRI on r128 (i.e. it causes lockup when X tries to do 2D-accelerated function). I read that CCE and DRI didn't mix well yet, but only now thnx to your email I realized this is the cause of the lockups I've been experiencing. > This isn't an issue anymore with current CVS as it uses the CCE exclusively > when DRI is enabled. That's why I only committed it to the DRI CVS once that > change was made there. Thnx dude, one point less left on my linux wishlist. Now I can throw my VCR away :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg01995/pgp0.pgp Description: PGP signature
Re: [Xpert]Tearing on overlay surfaces
Hi! On Sun, Dec 02, 2001 at 10:11:38PM -0800, Mark Vojkovich wrote: > DMA won't make the transfer go any faster (it will probably > be slower unless you're using 2x+ AGP), but it won't eat the > CPU. The only drivers that do this are NVIDIA's binary > drivers and supposedly some experimental ATI drivers that > some people are working on. (I am a co-author of the DMA-enabled Xv*PutImage for r128 you mentioned) As you probably have detailed reports on how this DMA-enhanced Xv*PutImage works on nvidia, don't you have stability problems with certain players? I noticed that while I never had troubles with aviplay or mplayer, vlc was not properly programmed and one thread liked it a lot to kill a Xv*PutImage running in another thread (has likely been fixed already but I haven't checked yet), which caused total machine lockup. Xine also causes lockup from time to time. Don't you have this with nvidia too? How did you solve it (if that isn't confidential information )? BTW as for "experimental": I've been using it for about 3 months now and until I bought some DVDs and started watching them it was super-stable, I certainly watched over 100 divx with it. It is already supposed to be in XF86 cvs. > MArk. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- It's not a bug, it's tradition! msg01988/pgp0.pgp Description: PGP signature
Re: [Xpert]The trouble when two Xv programe are running at the same time
On Thu, Nov 22, 2001 at 11:50:19AM +0100, Michel Dänzer wrote: > > Or am I missing something here (as usually )? > Yes, only one image can be displayed at a time per port so why bother. How "displayed"? If the image is already on the visible part of the screen, does it magically disappear when you tell the card to do scaling/conversion/drawing into another window? If it did, that would be "a really stupid thing" (TM). Are you sure this "magical disappearance" is caused by card's hardware and not some X obscurity? > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". msg01664/pgp0.pgp Description: PGP signature
Re: [Xpert]The trouble when two Xv programe are running at the same time
On Wed, Nov 21, 2001 at 11:50:57AM -0800, Mark Vojkovich wrote: >This is an application bug. Apps are supposed to Grab the > port when they want to use it so noone else can. When an app > tries to grab the port and finds that it is already grabbed > it will know that it is in use and it should fall back to some > other method to display the video. When the apps do not grab > the port they are using, continual preempting of each other's > video is the expected behavior. Hmm, does it really have to be like this? From my understanding of how XvShmPutImage is implemented on most cards, there should be a way to implement this reasonably: - make sure when allocating offscreen memory for data that it doesn't overlap - make sure when *CopyData422/420 are using DMA that only 1 DMA transfer happens at a time (dunno, is this really necessary?) - make sure calling *DisplayVideo422/420 only happens once at a time (from my experience this takes an insignificant amount of time => chance that these 2 will overlap is low => can be ignored So, in theory, making sure the allocated memory segments don't overlap should be enough. As the CopyData422/420 takes almost all the time of the PutImage function, there shouldn't be any strage slowdown besides lineary proportional to the amount of data transferred (i.e. image size*depth). Or am I missing something here (as usually )? > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. msg01661/pgp0.pgp Description: PGP signature
Re: [Xpert]s-video output for linux?
Nazdar! On Tue, Nov 20, 2001 at 11:14:33PM +0100, Daniel Smolik wrote: > Peter Surda wrote: > > I think you're better out buying a hardware converter, I think the thing is > > called "scan converter". These things cost about 150$ and are usually > > OS-independent. > But it has ugly quality of picture. Matrox is the best but > only the G400. G450 is not supported. Actually I've been told by someone who has a scan converter (I don't have one myself) that the quality is very good. It probably depends on the type. I can only speak for voodoo 3500tv (pretty low quality) and r128 (pretty good quality) from personal experience. I can't tell Matrox quality, I have never seen one myself so I can't compare. As for CPU-usage, due to DMA-accelerated XvShmPutImage, r128 currently surpasses every other card in linux, watching NTSC DVDs with SVideo TVout eats only about 15% CPU (i.e. 85% CPU free) on my Duron650. And I'm not even using hardware-accelerated idct or motion-estimation. > Dan Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Disc space - The final frontier. msg01615/pgp0.pgp Description: PGP signature
Re: [Xpert]s-video output for linux?
On Sun, Nov 18, 2001 at 09:14:50AM +1200, Bill Brower wrote: > Are there any Linux-compatible video cards that > support the S-video output feature? We'd like to > send the monitor output (preferably high resolution, > 1024x or 1248x) to a VCR for recording operator > action with an application. Voodoo3 3500 TV can do 800x600, r128 and radeon have patches for tvout as well and can also only do 800x600. Matrox: tvout it supported, dunno what max resolution. I think you're better out buying a hardware converter, I think the thing is called "scan converter". These things cost about 150$ and are usually OS-independent. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. msg01551/pgp0.pgp Description: PGP signature
Re: [Xpert]DGA problem with Voodoo3
On Mon, Nov 12, 2001 at 04:45:14PM +0100, Michel Dänzer wrote: > Use -vo xv or -vo sdl (the latter should automatically use the method > best suited for your setup). ... + you forgot to mention our wonderful DMA422CopyData which also causes less CPU usage compared to memcpy under DGA. Anyone actually ported it to other cards than r128? I'll do mach64 when it is DRI-ready. > Most apps that require DGA for fullscreen are broken. I agree somewhat. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. msg01403/pgp0.pgp Description: PGP signature
Re: [Xpert]DGA and PseudoColor
On Sun, Oct 28, 2001 at 11:38:19AM -0800, Mark Vojkovich wrote: >You might want to try XFree86 CVS. There was some miscommunication > about how the XFree86 colormap layer worked and I believe earlier > versions of the "ati" driver had problems when the root window was depth > 15 or 16 and trying to run a depth 8 DGA mode. I'm runnning "X -depth 8" when trying this, but I only use 8bpp for some games in wine. It worked some time ago, but I've upgraded X, wine and whole system in between. > If colormaps in depth 8 DGA works when your main X desktop is depth 8 (using > your current setup) that's probably what the problem is. I > believe Marc fixed this a couple months ago. I'm using a mix of gatos' driver and my own patches now :-) > If your colormaps don't work even when the main X desktop is in depth 8, it > might be a different problem. Could you recomment a prog that can test it? Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. PGP signature
Re: [Xpert]DGA and PseudoColor
On Sun, Oct 28, 2001 at 12:25:56PM +0100, Arne Caspari wrote: > Hello, hi > i want to change the colormap-entries of an 8-bpp PseudoColor > mode. Unfortunately it does not work. Actutally I seem to have trouble with palette in 8bpp in DGA as well (mach64 and r128, 4.0.3 and 4.1.0), but I'm not sure if it isn't the app's fault. Could someone pls check if palette is working in 8bpp dga? Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows." PGP signature
Re: [Xpert]ATI r128 pro with 32bits colors: working ?
On Thu, Oct 25, 2001 at 08:02:02PM +0200, Stephane APIOU wrote: > Hi! hi > i have an ati all in wonder 128 pro which is working well with 24 > bits/pixel. I have a non-pro which should be the same, just with other tv chip. > recently i started the X server XFREE 4.1.0 with 32 bits/pixel. > and it does'nt work ... why ? > is it not implemented yet? correct. > and in the future ? Dunno why it isn't supported. The docs seem to indicate that the card can do 32bit. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? PGP signature
Re: [Xpert]Capture support for ATI All-In-Wonder cards
On Tue, Oct 23, 2001 at 06:50:48PM +0400, [EMAIL PROTECTED] wrote: > Hello Volodya! > I just have seen your message on Sourceforge.net/projects/gatos/ > regarding capture support now appeared for ATI All-In-Wonder cards. > Could you give some instructions on what files to download and how > to try it, supposing I am not very much familiar with CVS trees and > development history? > I have Celeron366 + AIW Pro (Mach64), Linux RH 7.1 + XFree86 4.1.0 > (+ ati.2 already working fine for watching TV). Well you can find the docs in the km "distribution" in the files area in gatos' sf site. However it is a hard hack really and I don't think it can be used to actually do real caps (yet) ;-) > Best regards, > Nikolai Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Dudes! May the Open Source be with you. PGP signature
Re: [Xpert]ATI Mach64 feature requests
On Mon, Oct 22, 2001 at 09:57:10PM -0400, Shawn Starr wrote: > I don't see DRI in XFree86 CVS :( for Mach64. Because it is in separate branch in DRI cvs. Check out dri-devel mailing list. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- To boldly go where I surely don't belong. PGP signature
[Xpert]Re: [Dri-devel] my X-Kernel question
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote: >Would you consider it a good idea to make DRI part of the source of a >kernel? Direct 3d graphics supported from the boot sequence. Hmm I thought DRI is part of the kernel? Perhaps you meant the DRM part of it. >I'm really concerned about your answer. There was a whole thread on >the linux-kernel mailing list about the hypothesis of the release of >an X-Kernel, a kernel which would include built-in desktop support. I think it is a great idea to have a kernel implementation of Xserver. But it would have to be more modular than current XF86, and also have a highly flexible structure, so that adding new types of devices and functionality wouldn't pose problems. I think this is currently the biggest XF86's drawback. It would allow many cool things that XF86 is now struggling with (e.g. check xpert mailing list for thread about precise vsync coordination). Each device would have flags like: - can the device serve as a keyboard? - can the device serve as a pointer (mouse, joystick, touchpad, ...) - can it be used for video output? - can it grab/capture? - can it convert between colorspaces? - can it do DMA? This would allow to write drivers easily and also support combined devices (keyboard+touchpad, video+capture, ...). Second: provide data structures - keypress - mouse movement - image - font etc. and hooks for these devices to: - input data (e.g. keypress). - output data (e.g. draw pixel) - transfer data (from/to other devices, system RAM, etc). - combination of those (e.g. transfer an image from system ram and draw it) - process data internally (e.g. deinterlace?) - report status (refresh rate, vertical retrace, ...) - do something (e.g. wait for nth vsync) (think ioctl). Currently in XF86 (IMHO) for each new type of use a new standard has to be made. In this "ioctl" version you simply define a new value and add a function to a driver that should do it. Other drivers, or older X (as they would have something like "switch (ioctl) default: return E_UNSUPPORTED;") will return an error, but nothing will crash or seize to work. Another thing is code reuse, so that several drivers can call generic functions for doing the same thing (I think the "combination of transfer + output" is a very good candidate for this). This is also a problem in XF86 imho. >Most people answered, no, this would be ridiculous, I wouldn't put it on a server there because imho server shouldn't even have a monitor (mine don't). But for embedded and desktop, all way. But supposing you want to use a graphical interface on a box, then this kind of stuff simply DOES belong to the kernel (no I'm not an idiot and I don't have MSWindows anywhere on my computers). >other said, yes, but hardware manufacturers are too unhelpful therefore >this would be totally a totally unstable release. There isn't a reason why Xserver in kernel should be more unstable than user-space Xserver. Both have direct access to all memory and hardware and can lock up the machine. One thing though: There should be an interface to reload a driver that is currently in use, so that when developing it I wouldn't have to reboot everytime I recompile it. Oh and one more thing: the driver should autodetect if it is running on the same videocard as the virtual terminal stuff, so that the first card will simply open a new VT but secondary card will run independently of this VT stuff. This would finally allow a decent way to concurrently run 2 separate X sessions on the same machine using local hardware. >Others said.. other various things. Ok I'll check the thread. >So, what do you think? So, what do YOU think? :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Reboot America. PGP signature
Re: [Xpert]ATI Mach64 feature requests
On Sun, Oct 21, 2001 at 07:02:42PM -0400, Mike A. Harris wrote: Hi Mike! > 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 Is actively being worked on, it even supposedly works to some amount. Check out dri-devel. > 2) Xvideo support, video in/out, TV tuner, etc.. Xv -> is there DMA+Xv -> I'll do it as soon as I can upgrade my system to RH 7.2 and get Mach64's DRI working (so I can finally watch DVDs and divx in acceptable quality on my notebook). Video in/tv tuner -> I think it works. Capture is being developed. Video out -> I'll try to do it as well, but I don't promise anything :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". PGP signature
Re: [Xpert]Re: XVideo and refresh sync
On Sun, Oct 21, 2001 at 10:11:36AM -0700, Billy Biggs wrote: > How do the ATI cards currently export TV output capabilities when you're > writing interlaced frames? Hmm you can ask the card stuff like: - are you drawing or retracing? - are you drawing an odd or even frame? I am not sure if you can ask it whether it's NTSC or PAL. Anyway, currently when using TVOut on ATIs, the "Vertical Refresh" value xvidtune shows is wrong, it isn't taken from the tv encoder (I doubt my TV is 85Hz ). If you tell the yuv scaler to sync, it only syncs on one type of retrace (I don't know if it's even or odd frame, but it is definitely only one of them). Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. PGP signature
Re: [Xpert]Re: XVideo and refresh sync
On Fri, Oct 19, 2001 at 06:45:07AM -0700, Billy Biggs wrote: > > > The +/-5ms error here is visible, especially on big cinematic pans. > > I REALLY doubt what you perceive as an error is a 5ms difference. > No? I'll post up a good example later today. Consider a pan where > the time between frames goes like this: 40ms, 45ms, 35ms, 45ms, 42ms... > So, the second frame is shown for much longer than the first or third. it's a 1frame difference if you have 100Hz refresh. I REALLY doubt a human eye can see the difference. I bet it is something else causing you to see disturbances. To see the 80ms disturbance I was talking about (missed frame on TVout) you already have to watch out a little. 10ms (45 - 35) is 8 times as difficult. Please don't understand me wrongly: I agree that the current situation is insufficient. I simply think that the cause of your problems is not exactly what you think :-). > Speaking of TV output, if you're outputting interlaced material to a > TV then you MUST have accurate vsync, field dominance, and some way of > ensuring you never miss a field. Otherwise you get crazy effects of > people jumping back in time when you miss a field blit. My ATI does this on HW (AFAIK), i.e. it understands it can't blit both on even and odd frames. > Ideally for playing 24fps on a 25fps output, You don't have 24fps source usually. DVDs, dvd rips and tv caps are either 25 or 29.9 (PAL vs NTSC). But I agree that a 24fps on TV will look sucky unless you modify playback speed. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Intel: where Quality is job number 0.9998782345! PGP signature
Re: [Xpert]Random X crashes or total lockups
On Sat, Oct 20, 2001 at 07:07:03PM -0700, Mark Vojkovich wrote: > > Hey there... ]) powered by LINUX, preemptible kernel 2.4.12-ac3 ([ > Sounds more like you have a kernel bug. Not necessarily, for some strange reason when I tell vlc to go fullscreen it causes a X lockup as well (screen goes blue), I have to kill vlc and X over ssh. No other player (mplayer, aviplay) does that on my r128. Strange things can happen :-). > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Reboot America. PGP signature
Re: [Xpert]Re: XVideo and refresh sync
On Fri, Oct 19, 2001 at 12:21:12AM -0400, Billy Biggs wrote: > The +/-5ms error here is visible, especially on big cinematic pans. I REALLY doubt what you perceive as an error is a 5ms difference. Though I agree that current vsync adjusting in XF86drivers (those that support it e.g. ATI) is insufficient. I see noticeable disturbaces on TVout (thought not on monitor), I believe it is because from time to time the thread that calls XvShmPutImage has "missed" one frame and suddenly the difference between 2 frames becomes double. I see that 80ms (2 frames on 25fps TV) difference is noticeable, though I doubt 5ms is. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? PGP signature
Re: [Xpert]Fw: video rendering using HW scaling
On Thu, Oct 04, 2001 at 05:21:43PM +0200, Michael Zayats wrote: >to summarize: I have buffers with 24bpp RGB and want to put it fast >and CPU-economically in X11 window. DMA-accelerated Xv[Shm]PutImage should help. For implementation on r128 check out dri-devel archives. But I'm pretty sure hardware doesn't do RGB scaling though, you'd have to convert it to YUV first. To Michel Dänzer: have you managed to put the patch into CVS already? >Michael Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- rm -f /bin/laden PGP signature
Re: [Xpert]Implementing XvPutVideo
On Wed, Sep 26, 2001 at 06:02:59PM +0500, [EMAIL PROTECTED] wrote: > Hi All, hi >Im trying to implement XvPutVideo for our hardware. The existing driver > we have supports XvPutImage. > When I try to use XvPutVideo, I get a "BadMatch" error. I'm a novice to X > programming and would like to know what causes a BadMatch error. > One thing I'm sure of is that the call is not propogating to the driver > code, its is being flagged as an error before reaching the driver. Have you set the pointer to the function? I.e. card->PutVideo = MYPutVideo; >I will be really grateful for any pointers to writing a Xv driver. Use the source . I don't find it that complicated ... Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Disclaimer: This E-mail, because of shabby security on the Internet, in no way reflects my thoughts or intentions. It may even not be from me! PGP signature
Re: [Xpert]ATI Radeon: TV-out enable/disable
On Tue, Sep 25, 2001 at 07:17:04PM +0300, Mikko Rantalainen wrote: > I'm using ATI Radeon SDR with TV-out (PAL) and I have CRT-projector attached > to TV-out. Thanks to ATI's automatic detection of TV, the card starts with > TV-out and maximum refresh rate supported is 50Hz. You mean the "radeon" driver WORKS with tvout? Until today I was convinced it doesn't. > Is there some option that I can use in XF86Config-4 to enable/disable TV-out > or do I really have to disconnect S-Video cable each time I reboot to Linux? I'm actually working on it (tvout support) and one of the things will also be supported is what you want (selecting higher refresh rate for monitor if tv is connected), but on r128 driver. radeon and mach64 will be supported later. Just wait a couple of weeks/months and it will be there. > - Mikko Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- It's not a bug, it's tradition! PGP signature
Re: [Xpert]Trident Cyberblade XP XV support
On Mon, Sep 24, 2001 at 06:49:43PM +0200, Anders Rune Jensen wrote: >If I want tv-out to work, will I have to use framebuffer or will it >also be included so that I can use xv on tv-out? Suggestion to driver maintainer: try the same trick I did with ATI: add switching to vesa mode inside the init_video_mode function. It isn't perfect but very close. Now that I have access to ATI docs I'm trying to make it perfect :-) Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Disclaimer: This E-mail, because of shabby security on the Internet, in no way reflects my thoughts or intentions. It may even not be from me! PGP signature
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 07:26:47PM +0200, Matthias Dahl wrote: > > So the signal is generated the same way and indeed you should need to sync > > drawing. > But you shouldn't forget that one is progressive and other one is interlaced. yes there are 2 of them. > And I guess the TV does all the synching itself - it's its job and not that > of your graphic card - IMHO. No, the card tells the monitor or tv stuff like start drawing NOW retrace there draw again retrace back TV or monitor are pretty stupid, the card must tell them everything. > Well... I guess you would run into trouble of you are trying to display your > video material at 67 Hz on your 50 Hz TV... so frequency is indeed an > important factor. ;-) Yeah sure then some are missed, but still this has nothing to do with the topic: retrace sync must be done anyway. > > I believe that my routine simply waits for A retrace > Does your ATI card provide two independend register of retrace? (one for that > of your monitor and one for your TV out) No, but you can apparently choose which one will be taken into account. I hope the last sentence didn't reveal any confidential information about ATI But I was able to find a register that tells you if it's odd or even frame and I adapted the Xv function to take it into account. However I'm unable to see whether it helped. If someone on the list knows a video that is freely available and good for determining whether syncing to retrace works, I'd be very pleased if he/she sent me the URL. > > I find xine cubersome to use, in fact I was unable to actually get it working > > :-) Of course everyone will claim their player is the best . > You are absolutely right. :) Yet you should give a recent XINE version a > chance to proof itself... maybe you will be surprised. :-) Well I didn't mean that it doesn't compile, on the contrary, it compiled without hitch, I was just unable to do anything useful (like playing videos) with it :-) > So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- /* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */ /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */ PGP signature
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 04:52:24PM +0200, Matthias Dahl wrote: > > As he also pointed out that hardware automatically does this. > That depends on the hardware - matrox cards unfortunately don't do this > automatically. And I guess if it did, some people would complain about > it because they want the best possible frame rate. :( Well, you can't get higher frame rate than your monitor can go can you? Unless your brain is plugged directly to the videoram :-) > Maybe I am wrong but I don't think your TV out does need to synch with your > TV - and I don't know if this is possible at all. Actually I don't know that much about TV either. But TV is similar to monitor in that both are CRT-based. So the signal is generated the same way and indeed you should need to sync drawing. > As far as I understand it those tearing artifacts are caused by different > frequencies (your video material is 29.xx fps but your monitor for example > runs at 68 Hz) I don't think so. > and the different "formats" (your monitor is usually a progressive > display while your TV is a interlaced display My current theory is indeed that this is something with interlacing. I believe that my routine simply waits for A retrace, and not a FIRST retrace of the two, hence the 2 pictures sometimes overlap. > - I hope I am not making a fool out of myself and those things I just > said were right!). I believe you are partially right. > So your TV out should now deliver the frames in the right frequency (50Hz > for example) and in the right format (interlaced). That should be it. So > IMHO your are looking at the wrong thing to find the cause for your > problem... I still think that the problem is caused by retraces not being synced to data transfer. It doesn't matter that the frequency is lower or it is interlaced, you can't expect the picture to look ok if you transfer data to videoram while the ray is drawing. > Yet I think this could cause a bit of trouble. If your system is under > heavy load, you could easily miss the right time. Well, that's why we have patches for preemptive kernel and low latency. Unforutnately the preemptive patch causes crashes and segfaults pretty often, so I'm sticking to lowlat. For more than 75Hz I don't think you'll notice a difference whether a picture is displayed on 2 or 3 frames. Otherwise the latency would have to be bigger than about 1000/75/2 = 6ms and I don't think that happens even if load is high, unless you are too low on memory and in that case disturbances are expected to occur anyway. > So the function that is responsible for drawing the image waits even longer. It doesn't matter, it still looks better than 2 pictures mixed together. > On the other hand it's a step in the right direction (a quick workaround). > :-) Sure. > Now what confuses me is that I thought it isn't possible to get the retrace > information in user space - just in kernel space. I guess this is only true > if you want to make use of the hardware interrupt that is being issued (and > naturally that would be the best solution IMHO). I think you're right on this. > But I still think there should be an official way (through the kernel space > drm drivers for example) to get that information and handle it in the right > functions (for example XvPutImage) by implementing an optional double > buffering that is only used if a) retrace information is available and b) > if the programmer explicitly asked for the feature. Hmm mga has some buffering stuff like this in hardware I've heard. > Thanks for the hint. I have tried avifile some time ago and was pretty > pleased with it. But now XINE has become my player of choice where I'm also > trying to contribute a bit. :) I find xine cubersome to use, in fact I was unable to actually get it working :-) Of course everyone will claim their player is the best . > Last but not least. Could you please cc your answers to my mail address > because I am not subscribed to the Xpert list - just using the archives. :-( k > So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Secret hacker rule #11: hackers read manuals. PGP signature
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 02:14:00PM +0200, Matthias Dahl wrote: > > What card do you have? > Matrax G400 MAX (and quite happy with the DH stuff *grin*) k. > Back to the original topic again. :) As Mark Vojkovich kindly pointed out, X > does not provide any way to check the vsync pulse. :( As he also pointed out that hardware automatically does this. At least ATI seems to do it when using monitor (but it fsckes up when I use tvout). Anyway, I tried getting it working on my ATI with tvout, and I found a register in the docs that signals retrace status, however it still doesn't mix. > I consider video output sync with the vsync pulse as quite important, > especially if you wanna watch high-quality video material on your home > computer. :( Indeed. I suggest you do what I did: look the register number in docs and add something like this code into MGAPutImage just before MGADisplay422 is called, or perhaps directly to the beginning of MGADisplay422 function: while (inreg(blah) == retrace_in_progress); while (inreg(blah) != retrace_in_progress); This will end at the beginning of retrace cycle. I've been told by other developers that inreg is so slow that this also ensures the "while" isn't called millions of times and eat up cpu. This ensures that when using XV to watch videos, the picture drawing is adapted to retrace and should get rid of blinking. This should work on mga. I still have to figure out why it doesn't work on my ATI and TVout. The code seems to synchronize to SOMETHING, but definitely not to TV's retrace. If you are interested on high-quality video watching on mga, you can join the avifile mailing list or perhaps even directly ask Zdenek Kabelac or A'rpi. > So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- I believe the technical term is "Oops!" PGP signature
Re: [Xpert]XVideo and vsync
On Fri, Sep 21, 2001 at 02:41:29PM -0700, Mark Vojkovich wrote: >Hardware should automatically synchronize stuff like Xv(Shm)PutImage > with the retrace. If you want a VSync pulse for some custom application > you're out of luck unless you write a kernel module to do it. It's > a hardware specific thing done with interrupts. Hmm then my tvout patch fsckes it up, because it clearly isn't synced on my tv. Or could it be that aviplay or sdl don't call xvshmputimage with sync on? will check > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- funny thats the third time since ive been on IRC today that i seen the word "slave" and "microsoft" in the same sentence PGP signature
Re: [Xpert]XVideo and vsync
On Fri, Sep 21, 2001 at 10:12:54PM +0200, Matthias Dahl wrote: > Hey there... ]) powered by Linux 2.4.8 ([ hi > I have run into a problem and I hope some of you guys can help me out. :) > Thanks in advance for your help and time! np > Is it possible to do some vsync synchronization with the XVideo (or any other) > extension? I vaguely remember that for mga you can use /dev/mga_vid. I think there is a generic interface somewhere in X but don't know where. > I need this for proper video output. Yet I could not find any hint > about any function in the X documentation. If this isn't implemented yet, is > there any other way to synchronize the video output with the vsync? What card do you have? > So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ gpg --send-key [EMAIL PROTECTED] --keyserver certserver.pgp.com or better yet, define a keyserver in ~/.gnupg/options, then gpg will download automagically any keys if necessary, works well under mutt too. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- PGP signature
Re: [Xpert]3D on ATI Mobility Radeon-M
On Fri, Sep 21, 2001 at 05:08:29PM +0200, Michel Dänzer wrote: > Yes, PCI GART is still disabled in source for the Radeon AFAIK. Hmm I thought pci gart isn't implemented yet for radeon? If it is, could the responsible developers please contact "R C" <[EMAIL PROTECTED]>, he is developing capturing for radeon AIW and told me he wrote to dri-devel about this (pci gart for radeon) several months ago, but got no response, so he was forced to work on his own kernel module. It would be nice not to split the DMA infrastructure. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- PGP signature
Re: [Xpert]Two ways to framebuffer
Hi dude. On Fri, Sep 21, 2001 at 04:07:11PM +0200, Michel Dänzer wrote: > When did you last try the fbdev driver? It supports DGA as of 4.1.0 and I > wonder why it should be slower than the vesa driver as both use the same > shadow framebuffer. I stopped using fbdev in January so may be I missed something. Shadow is sometimes slower (e.g. on videos), hence I used to run with disabled shadow. Anyway, is there really a reason to use vesafb + fbdev instead of vesa? I don't think so. The only reason I can think of is some obscure hardware combination in which pure vesa driver doesn't work. BTW did you get the patch for R128PutImage+DMA I posted with ICQ? It fixed the last bug I was aware of. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". PGP signature
Re: [Xpert]Two ways to framebuffer
On Thu, Sep 20, 2001 at 11:16:29PM +0100, Gustavo Carvalho Homem wrote: > Hello all: hi. > One thing I can't find in the documentation. Are there advantages (or > disadvantages) of using XF86_FBDev over XFree86 4.1 with fbdev driver ? I only see an advantage for situations where Xserver is missing for your card but there is a fbdev driver for kernel. If there is no fbdev driver for the card for the kernel, it is better to use Xfree's vesa driver, because it is slightly faster than vesafb+fbdev and also can do DGA. In the past using vesa was necessary to use TVOut on ATI cards, however I was able to get r128's tvout working and am on my way to get rid of the small bugs and support mach64 and radeon. > Any other relevant comments ? If there is a driver for your card for Xf86, forget it. > Thank you very much > Gustavo Homem Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. PGP signature
Re: [Xpert]Xv standard change proposal
On Thu, Sep 20, 2001 at 04:27:26PM -0700, Mark Vojkovich wrote: >XvPutImage pushes the data through the socket. With XvShmPutImage > (only available for local clients) data is stored in shared memory > so that the server just copies it from the client's XvImage itself. I get it now. It seems that I've been using the Shm version only without knowing it. It looks like there is only one PutImage function in the driver and the shm/socket ones are defined in X libraries, do I guess it right? > XvShmPutImage is a few times faster than XvPutImage, plus > XvShmPutImage doesn't stall the client while the transfer to the > server takes place. I C. I probably won't implement a XvGetImage in X then, only XvShmGetImage. If someone really needs it I won't stop him/her from adding it of course, I just don't need it and won't do it, at least not until I'm able to grab videos in a usable way . >XShmGetImage is blocking, so maybe it's not important for XvShmGetImage > to be asynchronous. Having to send the event (and receive it) probably just > increases the latency anyhow. OK, the event is a bad idea. Now I think I understand, it's the transfer over socket that has to be waited for. If you have shm, you simply mark it destroyed on the client and when X is finished drawing the segment gets deallocated, right? So no non-blocking then. Or I'll simply try to mimic a combination of X[Shm]GetImage and Xv[Shm]PutImage to make the new function[s] fit into the framework. > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- They called their place of existence the "Universe", not the "Great Programmer/Universe". PGP signature
Re: [Xpert]Xv standard change proposal
On Thu, Sep 20, 2001 at 02:39:06PM -0700, Mark Vojkovich wrote: >Sorry, I meant XvPutStill. aha. >There will need to be an option for a shm completion event > on XvShmGetImage so the client isn't blocked while the server > fetches the data. I must confess I don't know the difference between XvPutImage and XvShmPutImage, but I don't mind blocking, for performance reasons grabbing and encoding will has to be done in separate threads anyway. I'm an avifile developer and I know from experience that decoding into a buffer in one thread and displaying from the buffer in another thread allows the decoder to eat over 98% cpu even if real time spent transferring data into videocard takes over 25% (but dma does that so the drawing thread sleeps). Doing this on one thread would mean that these 25% will become wasted and additionally could cause latency problems. So my guess is that the program that grabs using the XvGetImage should grab into a buffer in one thread and a separate thread should encode the pictures (and another one sound) asynchronously. I really don't see a point in GetImage to be non-blocking, but perhaps I'm missing something here. BTW no need to cc anymore, now I'm subscribed :-) > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- NT, now approaching 23x6 availability. PGP signature
Re: [Xpert]Xv standard change proposal
On Thu, Sep 20, 2001 at 01:30:52PM -0700, Mark Vojkovich wrote: >Then the client API would be the same as XvGetStill but would use > an XvImage as the destination instead of a Drawable. Er, not quite. XvGetStill seems to have a Drawable as a source and Port as a destination. What I want is to have Port as source and XvImage as destination. But I think thats what you meant. > That's a fine API addition. Having the Bt829 copy the data to system memory > has implemenation issues though. Kernel support is required to make sure > the XvImage is swapped in and locked down while the hardware dumps data to > it. That's primarily why something like that hasn't been added. Yes I understand, however kernel support is not necessary in that large scale. I planned to implement it on r128 similarly than I did it with XvPutImage. The data won't be transferred into XvImage at first, but into DRM buffers, and memcpy-ed from them to XvImage. My tests show that this extra memcpy causes CPU load of less than 1% on DVD-sized videos (720*512*16bit*25fps = approx 18MB/s) on my Duron 650, which is imho negligible. Of course this would require an addition to DRI definition as well because such a thing (DMA from videoram to RAM) hasn't been done yet. Fortunately ATI was so kind as to accept me as an official developer and since a couple of hours I have access to the hardware docs. Another developer from gatos project is trying to do a similar thing and we'll cooperate on doing "something". I'm already on my way to persuade DRI developers to add a new function for this DMA transfers as well. However, my first implementation will definitely be without DMA (just a simple memcpy), to see whether it works or not. Perhaps it will actually be good enough on my AIW to be usable, but for radeon DRM is definitely needed, the developer I mentioned told me standard memcpy can't transfer data fast enough on his computer. I have source of 4.1.0 on my box, I will try to add this XvGetImage function and try a non-dma implementation for my r128, perhaps even adapt a video grabbing proggy to use it and will report my results then. I think that this non-drm implementation shouldn't be that difficult. > Mark. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- three saints: looser & lamer & hacker PGP signature
Re: [Xpert]Xv standard change proposal
On Wed, Sep 19, 2001 at 07:52:16PM -0700, Mark Vojkovich wrote: > > I'd like to propose a change to Xv standard, to add a function > > "XvGetImage", > > which could be used to transfer data from videoram to system memory. 2 > > possible situations it can be used: >What's the prototype look like. Ie, what's the source. Port > or Drawable? Hmm I haven't gone so far yet, I'd like to find out first whether my idea has support in general or not. I'm looking at R128's XvPutVideo function now, and I think the proposed XvGetVideo should look similarly, but instead of copying the data from bt829 to a different place in video memory and telling the card to perfom YUV conversion and scaling, it should be copied into userspace. Hence it seems to be more reasonable to have Port as a source, as it will allow to capture without displaying something which actually is what I want. I.e. something like this: int XvGetImage ( ScrnInfoPtr pScrn, short src_x, short src_y, short dst_x, short dst_y, short src_w, short src_h, short dst_w, short dst_h, unsigned char* buf, // pointer to userspace pointer data); // information about port and stuff Hmm as I think more, having Drawable as a source could also allow interesting stuff, like capturing over network (if you use remote Xserver). What do you think? Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- PGP signature
[Xpert]Xv standard change proposal
Hello! I'd like to propose a change to Xv standard, to add a function "XvGetImage", which could be used to transfer data from videoram to system memory. 2 possible situations it can be used: 1. grabbing data from tv-decoder such as ATI AIW series. AIW doesn't have a v4l interface, I guess because it would clash with X drivers. 2. using the card to do accelerated colorspace conversions for video recompression programs. I need it for point 1 and IMHO Xv is logically the correct place for such a function. What do you think? Please CC me, I'm not on the list. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Where do you think you're going today? PGP signature
