Re: Fwd: [XFree86] fullscreen modelines
> I have a problem with tv dvd and video fullscreen with a flat panel > LCD 19 SONY in DVI-D". I use by default a resolution 1280x1024 but > when I watch TV , DVD and VIDEO I would need 1280x960 otherwise I see > 1 horizontal black centimeter on top and bottom of the screen. 1280x1024 flat panels are not 4:3. If you actually did get a 1280x960 modeline to work (which I do not think makes sense), the video would be stretched. The black bars are supposed to be there. I do not think it makes sense to change the resolution of your flat panel, since it is physically a 1280x1024 grid. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Fullscreen DGA really slow
Martin MOKREJ? ([EMAIL PROTECTED]): > > > > > > 1200 reps @ 5.1985 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 1200 reps @ 5.2014 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 1200 reps @ 5.2001 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 1200 reps @ 5.2020 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 1200 reps @ 5.1998 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 6000 trep @ 5.2004 msec ( 192.0/sec): ShmPutImage 500x500 square > > > 4 reps @ 2372.4955 msec ( 0.4/sec): GetImage XY 500x500 square > > Ah, sorry I haven't realized the difference between those 2 tests. :( > So Radeon 9200, AGP8x but in XF86Config only 4x speed > > 320 reps @ 17.2322 msec (58.0/sec): ShmPutImage XY 500x500 square I believe you that you have a problem, but again you have shown the wrong test. You ran: x11perf -shmputxy500 XY images aren't what you want. That operation is expected to be slow. You wanted to run: x11perf -shmput500 -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 2d performance info
Hi Ed, I would rather discuss 2D performance than mga_vid but I am not sure where you want to go since your reply focused mostly on mga_vid. I'll explain my position a little better on mga_vid though, hope it's useful. Ed Sweetman ([EMAIL PROTECTED]): > >>>Don't trust this. The video stuff is often quite hacky and it's > >>>not very good, even for this 'well supported' card. Specs are > >>>widely available yet all of these drivers could still use a ton of > >>>work, and now the cards are getting quite obsolete. > >> > >>Dont trust it in what way? I have a G450, I've hacked mplayer's > >>matrox driver to utilize the backend scaler for triple buffering and > >>i've most definitely seen the difference compared to straight xv. > >>It definitely works well on the G450 and support is nearly > >>non-existant for any other card in this area as far as i know. > > > > OK here is what I know, tell me where you think it is wrong. > > > >With mga_vid the application writes directly to video RAM, a > >performance gain, and it is triple buffered to avoid tearing since > >the hardware page flips on retrace. XFree86 4.2 (finally) included > >the patch double buffered XVIDEO in the mga driver. XFree86 is now > >effectively triple buffered, since applications write to system > >memory, and you can have one frame queued waiting in video memory. > > > >So the only difference between mga_vid and XVIDEO right now is that > >with XVIDEO, the X server copies the next frame from system memory to > >video memory, while mga_vid lets the application write to video > >memory. There is no tearing in either, only a speed difference. > > > > Disadvantages to using mga_vid: > > > > 1. It is in conflict with the X server and fbcon drivers for the > > same hardware. Switching VTs while mga_vid is being used causes > > system crashes. There is no locking for these competing drivers. > > XVIDEO colour key gets out of sync with the mga_vid colour key. > > first off, mga_vid does not need fbcon, and everything is more stable > when fbcon is not enabled and being used. I've yet to see mga_vid > cause a crash on my X when switching VT's (not that you'd ever need to > really). I dont know why or what color keys getting out of sync > between the two video output methods matter since they use the same > hardware and thus cant be used at the same time. Just like xv cant be > used to display two video outputs on the same screen at the same time. I know mga_vid does not need fbcon, if things are more stable when it's not being used, doesn't this indicate that something is wrong? I wrote the mga_vid driver for my application, and I have had bug reports about crashes on VT switching. So has mplayer [1]. > > 2. mga_vid assumes the 'end' of video RAM is available and does not > > coordinate with the X server for allocating video memory. It has > > been known to cause corruption of the desktop and app pixmaps. > > I've used mga_vid for months. I've seen no corruption of anything and > my desktop is pretty big. I have dozens of windows with plenty of > pixmaps in all of them open all the time across 4 desktops of > 1280x1024 @ 32bpp (24bpp with 32bpp framebuffer). I have had bug reports. Just looking at the source does it not indicate to you that this can happen? Is your X just not storing any pixmaps in off-screen memory? Maybe this is what backing-store did for you? Look at the mga_vid code: it just uses the "end" of video RAM and hopes it is not being used !! If anything was stored in the last 2M of video memory you would be screwed! > > 3. mga_vid's API is too simplistic and does not support the a > > scaling rectangle or line strides like XVIDEO does. > > Since i've seen mga_vid display video just as xvideo does, i dont see > how these other features matter. I can scale an mga_vid window TONS > faster than xvideo and doing so repeatedly does not crash X, which > doing so with an xvideo window does, as well as slow everything to a > grinding halt when it doesn't. I have never seen X crash or even slow down while I am resizing my application which uses XVIDEO on my G400. Furthermore, my application uses the clipping rectangle features of XVIDEO which our mga_vid driver does not support because the API is so simplistic. I've talked to the mplayer developers about this and we all agree that the mga_vid code is messy and hackish and should really be rewritten. > Nobody said it was the best way, but it performs better than the > alternatives. The "triple buffering" that xvideo does you say, still > doesn't produce video output that looks as nice as mga_vid's. And by > looking nice i mean motion looks smoother on 24fps video. there seems > to be a barely, maybe unconscious perception of latency difference. I think your system is just slow then if you see smoother video with mga_vid. Do you think the mga_vid is a good design? How do you see it fitting into the X architecture for other car
Re: [XFree86] 2d performance info
Ed Sweetman ([EMAIL PROTECTED]): > > > My config settings for my matrox g450 are aggressive with agp > > > enabled > > Does the open source driver use DMA at all? If it doesn't, do the > > higher AGP modes even help at all? > > for matrox? I believe so. I'm sure some drivers do not but i'd > suspect matrox's to. Can you back this up somehow? I have a Matrox G400 card. The open source "mga" driver clearly does not do DMA transfers for MIT-SHM uploads to video memory, nor for XVIDEO (see the source). Using Option "AGPMode" I see no difference at all in SHM or XVIDEO performance. Or did you mean something else by "aggressive with agp enabled" ? > RENDER does not use dma at all, which hinders performance a lot i > would think seeing as how render is used from anti-aliased fonts to > alphablending and the more programs use either the more render's > performance comes into question. How would RENDER use DMA? I know keithp talks about doing things like DMA'ing video data FROM video memory back to system memory in order to do compositing on the CPU, then send it back, but I think that idea is silly. > > > and backing store enabled, > > Is this good or bad? > good for drivers that can use it correctly. Bad for ones that cant. Can you tell me what this feature does and how it would help performance? > > > i'm being held back by this G450 despite all the support for using > > > the backend scaler and triple buffering for video playback that i > > > use often. > > > > Don't trust this. The video stuff is often quite hacky and it's not > > very good, even for this 'well supported' card. Specs are widely > > available yet all of these drivers could still use a ton of work, > > and now the cards are getting quite obsolete. > > Dont trust it in what way? I have a G450, I've hacked mplayer's > matrox driver to utilize the backend scaler for triple buffering and > i've most definitely seen the difference compared to straight xv. It > definitely works well on the G450 and support is nearly non-existant > for any other card in this area as far as i know. OK here is what I know, tell me where you think it is wrong. With mga_vid the application writes directly to video RAM, a performance gain, and it is triple buffered to avoid tearing since the hardware page flips on retrace. XFree86 4.2 (finally) included the patch double buffered XVIDEO in the mga driver. XFree86 is now effectively triple buffered, since applications write to system memory, and you can have one frame queued waiting in video memory. So the only difference between mga_vid and XVIDEO right now is that with XVIDEO, the X server copies the next frame from system memory to video memory, while mga_vid lets the application write to video memory. There is no tearing in either, only a speed difference. Disadvantages to using mga_vid: 1. It is in conflict with the X server and fbcon drivers for the same hardware. Switching VTs while mga_vid is being used causes system crashes. There is no locking for these competing drivers. XVIDEO colour key gets out of sync with the mga_vid colour key. 2. mga_vid assumes the 'end' of video RAM is available and does not coordinate with the X server for allocating video memory. It has been known to cause corruption of the desktop and app pixmaps. 3. mga_vid's API is too simplistic and does not support the a scaling rectangle or line strides like XVIDEO does. 4. Requires a kernel module. Advantages to using mga_vid: 1. Performance gain. It has been arguged that the performance gain is negligible if the XVIDEO driver actually DMA'ed frames to video memory, since AFAICT the card does support it, and it is done by Matrox's binary HAL driver for these cards. For an example of this, see the NVIDIA binary drivers, which use DMA and can get rockstar upload speeds using DMA. Having mplayer render to system memory and then the NVIDIA card upload it using DMA is faster than having mplayer write directly to video memory. It is unclear to me, especially given all of the disadvantages above, that the mga_vid design is the 'right way'. > > > And are there any other 2d Xfree86 benchmarks out there that > > > benchmark the functions and extensions actually used in X these > > > days like render and shape and pixmap manipulation and all that > > > stuff? > > > > I am not sure of one in particular but the ones we like to use for > > supporting our app are mostly just 'x11perf -shmput500' which is > > usually a good indication of what any sort of 2D app would need (at > > least it's a good estimate for video or 2D game performance). > > That's one test of one call. Hardly a measure of performance for the > average X users workload. No, like I said, it's a good indication for 2D video game performance, since it tests how fast MIT-SHM image uploads are. So, what SDL would use to draw graphics on your screen. > Though it is probably the most important c
Re: [XFree86] 2d performance info
Ed Sweetman ([EMAIL PROTECTED]): > My config settings for my matrox g450 are aggressive with agp enabled Does the open source driver use DMA at all? If it doesn't, do the higher AGP modes even help at all? > and backing store enabled, Is this good or bad? > i'm being held back by this G450 despite all the support for using the > backend scaler and triple buffering for video playback that i use > often. Don't trust this. The video stuff is often quite hacky and it's not very good, even for this 'well supported' card. Specs are widely available yet all of these drivers could still use a ton of work, and now the cards are getting quite obsolete. > And are there any other 2d Xfree86 benchmarks out there that benchmark > the functions and extensions actually used in X these days like render > and shape and pixmap manipulation and all that stuff? I am not sure of one in particular but the ones we like to use for supporting our app are mostly just 'x11perf -shmput500' which is usually a good indication of what any sort of 2D app would need (at least it's a good estimate for video or 2D game performance). -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Why does overlay lag behind with XVideo?
Thomas Winischhofer ([EMAIL PROTECTED]): > >>This is typical behavior of all overlays. The overlay doesn't update > >>until the next retrace but all other graphics draw as soon as > >>possible. > > > > > > But you can see the window moving. The problem is that the overlay > >doesn't get reprogrammed with a new position until the next frame is > >drawn from the input. So I draw a frame, the overlay is programmed to > >draw it at 50,50. I move the window to 75,75 overlay is still at 50,50, > >so my window moves faster than the video. Next frame is drawn by xine > >or whatever and now the video is at 75,75. > > > > It's a valid complaint, would be nice if the overlay position could be > >updated during window move, don't know how feasible it is. > > This is not possible with most hardware I know of. The engines usually > read the overlay parameters only once per frame, during retrace. I meant frame sent by xine. When you move an XVIDEO window around, I do not think you are just seeing inconsistency as tearing. With my application I can change the output framerate between 59.94 fps and 29.97 fps. When tvtime is drawing at 29.97 fps, the lag between window moves and the contents moving is much longer than at 59.94 fps. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Why does overlay lag behind with XVideo?
Mark Vojkovich ([EMAIL PROTECTED]): > This is typical behavior of all overlays. The overlay doesn't update > until the next retrace but all other graphics draw as soon as > possible. But you can see the window moving. The problem is that the overlay doesn't get reprogrammed with a new position until the next frame is drawn from the input. So I draw a frame, the overlay is programmed to draw it at 50,50. I move the window to 75,75 overlay is still at 50,50, so my window moves faster than the video. Next frame is drawn by xine or whatever and now the video is at 75,75. It's a valid complaint, would be nice if the overlay position could be updated during window move, don't know how feasible it is. -Billy > > > Mark. > > On Thu, 6 Nov 2003, Hakon Gunsen wrote: > > > Hello! > > I have a nvidia gforce2 card, and with mplayer or xine I use the Xv extension > > output plugin. > > But I have noticed that the video overlay lags behind in position as I move around > > the player application on the desktop. Small problem, but anyways I'd like to know > > what type of card I should buy to avoid this, so that the video moves along just > > as fast as when I use the xshm output. > > > > Hakon > > > > > > > > > > ___ > XFree86 mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] mga_vid VT switching hangs
Monty ([EMAIL PROTECTED]): > On Wed, Nov 05, 2003 at 08:40:45AM -0600, Billy Biggs wrote: > > Ryan Underwood ([EMAIL PROTECTED]): > > > > > Just a quick and silly question: does anyone know if there is a > > > limitation in mga_vid's design, that causes a dead system when > > > switching to a VT from X while mplayer is using it? Of course, > > > this is one of those things where the obvious solution is "Don't > > > do that then", but I'm curious if I'm the only one that has that > > > problem. :) > > > > > > I have a G400MAX running dualhead with Matrox HAL, kernel 2.4.22, > > > XFree86 4.3.0 on Debian. > > > > When you have two drivers for the same hardware in conflict like > > that, I would expect problems. It's pretty well known that this > > causes hangs. > > Um, what exactly is the conflict here? That should certainly be a > safe operation. Every time you draw a frame using mga_vid you're reprogramming the Matrox card with the address of next frame, the overlay parameters, etc. When you switch VTs, X is also programming the card. These operations are not atomic. You have two drivers both programming the same hardware resource. If you think that VT switching should be safe, it's up to you to put forward a more convincing argument I think :) Just consider that mga_vid currently uses the end of video RAM and just assumes that hopefully X isn't using that for its pixmap cache or anything, and you'll understand a little bit more of the design. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] mga_vid VT switching hangs
Ryan Underwood ([EMAIL PROTECTED]): > Just a quick and silly question: does anyone know if there is a > limitation in mga_vid's design, that causes a dead system when > switching to a VT from X while mplayer is using it? Of course, this > is one of those things where the obvious solution is "Don't do that > then", but I'm curious if I'm the only one that has that problem. :) > > I have a G400MAX running dualhead with Matrox HAL, kernel 2.4.22, > XFree86 4.3.0 on Debian. When you have two drivers for the same hardware in conflict like that, I would expect problems. It's pretty well known that this causes hangs. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Fullscreen DGA really slow
Pieter Hulshoff ([EMAIL PROTECTED]): > On Sunday 02 November 2003 19:29, Billy Biggs wrote: > > Is it maybe related to this bug: > > http://bugs.xfree86.org/show_bug.cgi?id=414 > > You might want to test using some of the commands we mention there. > > I did, but to no avail. Their problem description also differs from > mine: I get pretty good performance with video or normal DGA access. > It's when I use the special xmame effects that I run into problems > with. Now as said: it works perfectly well with the Morphix CD I've > used, but using the X configuration from that setup doesn't help > either. So you compared the output of x11perf or xvtest ? I'm curious if you have stats for those. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Fullscreen DGA really slow
Pieter Hulshoff ([EMAIL PROTECTED]): > On Sunday 02 November 2003 18:26, Kevin Brosius wrote: > > Hmm, I'd suggest changing to this setting in the Screen section (from > > 24) > >DefaultColorDepth 16 > > if that's not faster, send the log file again. > > Tried it, but it didn't give any improvement. Here's the logfile... In that > setup I also disabled glx and dri. I've already tried using the Morphix > XF86Config file as well, but even that didn't help. > > It's not impossible that SuSE played around with the driver, while leaving > the version the same... Is it maybe related to this bug: http://bugs.xfree86.org/show_bug.cgi?id=414 You might want to test using some of the commands we mention there. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] X crashing in Red Hat Linux
Mark Vojkovich ([EMAIL PROTECTED]): > Xlock meaning the 3D screen savers? If so, perhaps not loading > the glx module (which, of course, disables 3D rendering) would > prevent the crash? This is more than likely to be this bug: http://bugs.xfree86.org/show_bug.cgi?id=144 -Billy > > Mark. > > > On Fri, 8 Aug 2003, IAM wrote: > > > Hi > > > > I'm having problem with X crashing on Red Hat 9 Linux during Xlock. > > This happens persistently on two new machines which are hardware > > twins, with Intel 845 onboard video. The problem occured also when I > > transferred to one of these machines the whole /etc/X11 structure > > from an older system with Linux Red Hat 8.0. Playing with color > > depth or resolution did not help either. My XFree86 version is the > > most recent one. > > > > I would appreciate any help or suggestions. Attached is a log file following one > > of the crashes. > > > > Thank you. > > > > Marek Labecki > > > > Institute of Applied Mathematics > > University of British Columbia > > Vancouver, B.C. V6T 1Z2 Canada > > Tel. 604-822-4584 > > Fax 604-822-0550 > > > > ___ > XFree86 mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Relationship of XVideo to V4L
Michael J. Hammel ([EMAIL PROTECTED]): > MythTV seems to want to work with V4L devices. My understanding is > that XFree86's v4l module will provide an Xv interface to V4l devices. > Is that correct? This assumes the TV is accessible through a V4l > driver, ie Xv sits atop V4L - is this also correct? XVIDEO does two things. It provides an API allowing applications to draw their own video to the screen, and it also provides an API to have X talk directly to the capture card simply for displaying on the screen (no capture). The driver you're using, afaict, can _only_ display video to the screen, and not capture. This means that mythtv CANNOT record using it. > If I'm right about this, the only way to support my hardware would be > either: > > 1. write a V4l driver for the TV hardware and make the X server not > manage that hardware Yes. > 2. Add direct Xv support to MythTV No. The XVIDEO API for displaying video does not provide a usable interface for recording video streams. Send the output of 'xvinfo' and you'll likely see that no capture capabilities exist anyway. -Billy ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] specific refresh rate
Daniel Bush ([EMAIL PROTECTED]):
> I am using:
> XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2)
>
> 1) How do I know exactly what refresh rate X is running @?
It's a pretty easy. The bottom of this email contains a shell script.
The formula is pixel clock in hz divided by the number of pixels, so
htotal * vtotal. Since pixel clock is in MHz in a modeline, multiply by
10.
> 2) How do I specifically set the refresh rate I want?
In X 4.3 the 'randr' program can help you easily switch between
defined modelines at various refresh rates, or you can create your own
modelines that have the refresh rate you want.
> I have examined my /var/log/XFree86.0.log and came across the following
> at the very end:
> GetModeLine - scrn: 0 clock: 65000
> GetModeLine - hdsp: 1024 hbeg: 1040 hend: 1176 httl: 1344
> vdsp: 768 vbeg: 770 vend: 776 vttl: 806 flags: -21474836
> I assume X is using 65Hz
Wrong. The dot clock is 65MHz. Your refresh rate is
(65000*1000)/(1344*806) or 60Hz.
> I have also tried to configure the following Modeline under the Monitor
> section but, it seams to have no effect:
> Modeline "1024x768" 97.40 1024 1072 1192 1416 768 768 771 809
This would be the same modeline with a high pixel clock and running at
89Hz. You could likely come up with an 89Hz refresh rate modeline that
was better aligned for your hardware, but you're going about it the
wrong way. X will choose the highest refresh rate mode available to it,
and it has alot of modes built in. You should likely make sure the
VertRefresh option (or your HorizSync option) in your Monitor section is
set to not be too restrictive, it will likely fix your problem.
-Billy
#!/bin/sh
#
# Print the refresh rate, assuming that the bottom of the
# output of xdpyinfo -ext XFree86-VidModeExtension is the
# current modeline, and that it's in the format I expect,
# which may not be true.
MODELINE=`xdpyinfo -ext XFree86-VidModeExtension | tail -1`
DOTCLOCK=`echo $MODELINE | awk '{ print $1 }'`
HTOTAL=`echo $MODELINE | awk '{ print $5 }'`
VTOTAL=`echo $MODELINE | awk '{ print $9 }'`
REFRESH=`echo "scale=2;($DOTCLOCK * 100) / ($HTOTAL * $VTOTAL)" | bc`
echo "Current refresh rate is $REFRESH hz"
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Getting notify event of vertical refresh
David N. ([EMAIL PROTECTED]): > The other part of my problem is that I'm trying to grab complete > images off of the screen using XShmGetImage(). Despite synchronizing > on with vertical refresh like you suggested, I'm finding that the > buffers that I capture with XShmGetImage() have tearing in them - i.e. > it looks like the next frame is getting drawn into X's buffer before > XShmGetImage is done retrieving them. > > In these cases I notice that XShmGetImage is taking longer than 13.3ms > to complete. Do you have any ideas on a quicker way to get a copy of > X's output buffer? I am not an expert in this area, but I can tell you that reading from video memory is extremely slow for most, if not all, consumer video cards. The path is not optimized and can take well longer than a frame to grab a copy of the framebuffer. Rumor has it that some cards, like newer nVidia cards, can use their DMA engine to transfer from video memory back into system memory, which would be useful for many applications which want to, say, render 3D graphics in realtime for some other purpose than display on the screen (like hardware accellerated raytracing). However, I do not believe that this is currently implemented in the nVidia binary drivers for XShmGetImage, or anywhere else by anyone else for that matter. I'd love to be proved wrong. -Billy -- Billy Biggs [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Getting notify event of vertical refresh
David Nahman ([EMAIL PROTECTED]): > I'm writing a program that needs to synchronize with the vertical > refresh of the screen in order to trigger an external piece of > hardware. Is there a way through Xlib to detect when a vertical > refresh has happened? Or is this something that is video card driver > pecific? This is currently video card specific. With nVidia cards and the binary drivers, you can use poll() on /dev/nvidia[0-x] to have your process block until the next refresh. With mga, radeon, r128, i830, (what else?) drivers, using the new DRM for X4.3, there is a DRM ioctl you can use to get information about the refresh rate. Look for drmWaitVBlank and associated code in libGL for how to use the ioctl. Other then that, there are a bunch of card-specific codes around providing refresh interrupts as kernel modules. In new versions of svgalib, they include a kernel module to provide this functionality through their API, although it's unclear if it is 'safe' for use along with X. As well, the mplayer program includes some kernel module drivers for overlay surfaces which includes some refresh sync code, but it's not really used by them currently to my knowledge. I'm working on some sort of library to abstract the nvidia binary drivers and the new DRM method, and maybe other methods if they are clean. If anyone else is interested in helping out with this, let me know. Hope that helps, -Billy -- Billy Biggs [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] bttv video
Tony Wright ([EMAIL PROTECTED]): > I've installed a cheap video capture card (it's a bt848 based card) > the trouble is is that when it runs it only shows a monochrome > picture, (it works fine in colour in windows) I have tried using > different "card" options in modules.conf but with no success. has > anyone had this problem before (and fixed it)? This is really a question for video4linux-list. https://listman.redhat.com/mailman/listinfo/video4linux-list What card do you have? If it's from the tuner input that you're only getting b/w, it's likely that the tuner is being misdetected. > also, is there a way of unloading and reloading the bttv module? Sure, rmmod bttv; modprobe bttv -- Billy Biggs [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
