Re: [Xpert]create a icon on desktop
You're on the wrong list, I'm afraid. X has nothing to do with desktops and icons thereon. You need to contact the people who created your windowmanager (KDE, Gnome, Windowmaker, etc). -Yuri On Thu, 25 Oct 2001, Louis Lu wrote: > Hi : > >Is there anyone who know how to to create a icon (short-cut as > well) on the desktop? therefore, I can just click the icon to run > the program. > > the executable file is located /root/sample. > > thanks in advance. > Louis ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Standalone Mesa vs. XFree86 bundled Mesa
Hi. I am sure these questions are answered in a FAQ, but I couldn't find this info on the mesa website nor in the xfree86 docs. (May have overlooked something.) 1. XFree86 4.1.0 contains (pieces of) Mesa 3.4.2. The most noticeable exception being glut, I guess. Are there other major parts of Mesa not being shipped with XFree86? (I.e.: if I get/build glut myself, is there any need for me to install the standalone Mesa unless I want the latest and greatest in bugfixes.) 2. I am aware of the licensing issue with glut. How did Brian get permission to bundle it with Mesa? :-) 3. Is there a plan for updating the Mesa bits in XFree86 as Brian keeps releasing new versions? Did execution of this plan stop dead in the tracks when VA Linux kicked the DRI team? Best regards, Dag B p.s. Paul, if you're reading this: could you add something about this to the mesa3d website. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]Dual Monitor (single or dual card?)
Well, RedHat 7.2 is apt to include less cruft... It's always been my observation that while Mandrake is certainly flashy, and reasonably secure, it suffers from severe bloat and occasional stability problems. As far as the video card, I can't confirm that the Colorgraphic cards will work, but most (all?) Cirrus Logic chips do... If they present themselves as separate BusIDs, it should work. Otherwise, I have no experience. If it doesn't work, the MGA G450 would be a good one (3D to boot) or two ATi Rage 128's (might have DRI issues, but should work fine otherwise). -Original Message- From: David Epelboim [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 25, 2001 4:05 PM To: [EMAIL PROTECTED] Subject: [Xpert]Dual Monitor (single or dual card?) Hi, We are going to update a computer to run some special software that works on Linux, and we are going to install Mandrake 8.1 or Red Hat 7.2 (What do you recommend?) The point is we actually own a Colorgraphic video card and we want to put it on multiscreen and/or multihead (multiscreen=xinerama). If not, we want to buy 2 cards or a dual head card, like a Matrox G450. Any tips or recommendations? Colorgraphic cards are dual Cirrus Logic. Thanks a lot. David. PS: Please send responses with copy to my email too. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Loosing My Cursor
Hey guys, I just redid my xconfig so that my new wireless mouse will work. It is working fine, my cursor however is not. It works fine when I log into X, but the first time I switch to a console ( ctrl + alt + f1) and then come back, my cursor becomes a big white box (about 100 pixels), with a small black line in the upper righthand corner. I am running debian/sid + enlightenment. On a Duron 900 + Matrox G400 with the mga and dri modules loaded by the kernel. I am not running gpm and have allready added the sw_cursor/ SWcursor lines to my XF86Config-4 file. Any idea how I can get a real cursor back? --Nate Custer P.S. I am not a member of the list so please cc me. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Thu, 25 Oct 2001, Sottek, Matthew J wrote: > > In light of ReputImage(), which I was unaware of. I think the first > proposal was best. I can make ReputImage() work without copying all > the data all the time. Assuming ReputImage() works. I've never used it, but others have (that doesn't mean it works correctly though). > Rather than copy the visible part of the XvImage to the offscreen > memory starting as the top left of the offscreen buffer, I'll copy > the visible region to the same x,y coordinates in the offscreen > memory. When the window moves triggering a Reput() either I can > show the newly exposed region as zero'd or clip the overlay to the > area that I actually have data for. Either way it is better than > leaving the overlay in the wrong screen location. That sounds OK. I didn't consider using Reput unless I wanted to autohandle exposures, but I guess there's no need for that since the client will get an expose anyhow. Hope ReputImage() works as expected. > > Here is the proposal again, if there are on complaints I'll > implement it this way. > > #define XV_HOLD 0x0 > #define XV_TOP_FIELD0x1 > #define XV_BOTTOM_FIELD 0x2 > #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Sounds OK to me. > > The atom XV_FRAME_TYPE can be set to one of the above values. > XvShmPutImage takes either an interlaced or progressive image > and copies both fields to the offscreen area. If XV_FRAME_TYPE > is not XV_HOLD the overlay is updated with the new data right > away. When it is XV_HOLD the overlay is not updated. > > At any time the atom can be set to XV_TOP_FIELD or XV_BOTTOM_FIELD > or XV_FRAME to display the result of the last XvShmPutImage. > > Mark, if we make use of Reput() couldn't you then make Blitted video > work? Reput() would just update the position during XV_HOLD but > not make a copy. Then when XV_TOP_FIELD was set the coordinates > would always be correct. Reput() could either do nothing or just > update the valid area when XV_FRAME_TYPE != XV_HOLD. > Assuming ReputImage() works properly and you still have the data around. Implementations that supply the data via the DMA buffer (like color expansion data) can't do much about that unless you saved off a spare copy. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]create a icon on desktop
I don't beleive that X has a desktop - or icon support for that matter, so it depends on what file manager you're running. Jeffrey H. Ingber (jhingber _at_ ix.netcom.com) On Thu, 2001-10-25 at 21:58, Louis Lu wrote: > Hi : > >Is there anyone who know how to to create a icon (short-cut as > well) on the desktop? therefore, I can just click the icon to run > the program. > > the executable file is located /root/sample. > > thanks in advance. > Louis > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]create a icon on desktop
Hi : Is there anyone who know how to to create a icon (short-cut as well) on the desktop? therefore, I can just click the icon to run the program. the executable file is located /root/sample. thanks in advance. Louis ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: ATI r128 pro with 32bits colors: working ?
On Thu, 25 Oct 2001, Stephane APIOU wrote: >Date: Thu, 25 Oct 2001 20:02:02 +0200 >From: Stephane APIOU <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=ISO-8859-15; format=flowed >List-Id: General X Discussion >Subject: ATI r128 pro with 32bits colors: working ? > >Hi! > >i have an ati all in wonder 128 pro which is working well with 24 >bits/pixel. > >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? and in the future ? > >thanks for help There is no such thing as 32bit color depth. XFree86 4.x has 2 settings related: depth, fbbpp depth == the number of valid bits used to indicate color information in a pixel fbbpp == the number of bits in video memory a single pixel consumes. Every video mode has a setting for both of these. The most common color depths are: 8/15/16/24 The valid fbbpp's are: 8/16/24/32 Combined, the possibilities are: depth/fbbpp 8 8 1516 1616 2424 2432 The XFree86 drivers when using depth 24, automatically use the fastest appropriate supported fbbpp for the given hardware. So when you state: depth 24 What you get, is: depth 24, fbbpp 32 Unless of course the video hardware you are using does not support 32bit packed pixel. Short story: You are already using 32bpp, which has 24 bits of color depth. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.org -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TV Out with nv
On Fri, 26 Oct 2001, Paul wrote: > Hi > > Does the built-in nv in 4.0.3 server support TV Out with GeForce 2MX ? I > don't want to use the nVidia 3D drivers etc. If so, is there a FAQ > somewhere that explains the settings required? > TV out is not supported in the "nv" driver. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
In light of ReputImage(), which I was unaware of. I think the first proposal was best. I can make ReputImage() work without copying all the data all the time. Rather than copy the visible part of the XvImage to the offscreen memory starting as the top left of the offscreen buffer, I'll copy the visible region to the same x,y coordinates in the offscreen memory. When the window moves triggering a Reput() either I can show the newly exposed region as zero'd or clip the overlay to the area that I actually have data for. Either way it is better than leaving the overlay in the wrong screen location. Here is the proposal again, if there are on complaints I'll implement it this way. #define XV_HOLD 0x0 #define XV_TOP_FIELD0x1 #define XV_BOTTOM_FIELD 0x2 #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) The atom XV_FRAME_TYPE can be set to one of the above values. XvShmPutImage takes either an interlaced or progressive image and copies both fields to the offscreen area. If XV_FRAME_TYPE is not XV_HOLD the overlay is updated with the new data right away. When it is XV_HOLD the overlay is not updated. At any time the atom can be set to XV_TOP_FIELD or XV_BOTTOM_FIELD or XV_FRAME to display the result of the last XvShmPutImage. Mark, if we make use of Reput() couldn't you then make Blitted video work? Reput() would just update the position during XV_HOLD but not make a copy. Then when XV_TOP_FIELD was set the coordinates would always be correct. Reput() could either do nothing or just update the valid area when XV_FRAME_TYPE != XV_HOLD. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]TV Out w/ 815 or Savage
I have been trying to find out (before buying one...) whether XF86 on Linux will support TV out on either: Savage 4D i815E / ICH2 (I guess with the Chrontel chip) Both are integrated on the motherboard. What resolutions are supported? The best info I was able to find is that some people got either BW only, or only filled 70% of the screen. Thanks Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]TV Out with nv
Hi Does the built-in nv in 4.0.3 server support TV Out with GeForce 2MX ? I don't want to use the nVidia 3D drivers etc. If so, is there a FAQ somewhere that explains the settings required? Thanks Paul ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI r128 pro with 32bits colors: working ?
On Thu, 25 Oct 2001, Peter Surda wrote: > 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. The trick is that when you request 24bits it is actually using 32 for each pixel. What the driver means is that each field (R, G, B) is only using 8 bit. > > > and in the future ? > Dunno why it isn't supported. The docs seem to indicate that the card can do > 32bit. and that's what the drivers use. Good think we don't have screen depth race.. Imagine cards which support 64bpp by requiring that two 32bpp pixels be always written at once ! Vladimir Dergachev > > Bye, > > Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 > > -- > 0 and 1. Now what could be so hard about that? > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]White Box Cusor
On Thu, 2001-10-25 at 10:34, Steven L. Sesar wrote: > My problem is with XFree86 4.1.0-7. After reconfiguring, > reinstalling, recreating XF86Config-4, and adding Option "SWCursor" > to my XF86Config-4 file, I cannot get rid of this white box for a > cursor. I suspect DRI enforces usage of the hardware cursor because it doesn't work without. You could try disabling the hardware cursor in matroxfb. (or fix the mga driver to reinitialize the hardware cursor in EnterVT ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GDM will not refresh after logout.
On Mon, 2001-10-22 at 19:29, Bill Schoolcraft wrote: > I'm encountering more and more cases of people using Gnome, > attempting to logout and not being able to return to the GDM login > screen. The screen just freezes shut (black). > > Of course I'm hearing it when it's at a "fsck /dev/" > level when they get wedged tight and power off the machine. Can > anyone suggest what may be happening ? > > I've bounced them down to runlevel_3 and it still happens too so I'd > suspect it may be more than just GDM. Possible, but I seem to remember there was a similar bug with older versions of GDM. You could also try playing with its option to always restart the X server on logout. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]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]I can make it! SIS630 under Mandrake
Hi. I write to know the opinion about some problem. You are XFree developer, so i think You know something. Its about -> reseting vconsole <- after X crash. Why ist so important? In my opinion XFree can not be 100% stable, because there are two _diffrent_ ways of developing: - making more stable, making perfect, - adding new features. 99% - yes :) Butt not 100% stable. So, when i work on XServer i _must_ be 100% sure that i will not lose control over my system. I have rarely X crashes, for example when i exit RTCWolfenstein3D, or when i must use SAK Sysrq+k (for example when program like VMWare steal the keyboard and crash). In result virtual consoles are damaged - they look like screen shot of Gnome for example. This i call: "losing control over my system" - i cant use vconsoles, i cant run programs on other /dev/tty than /dev/tty7 (after restarting xserver using blindly typed "startx")... I know that other people have that problem. Damaging vconsoles is not a good thing - they are base in linux. I know that this is probably kernel thing, however it relates XFree very much. So can You or someone give a signal to kernel developers? I will write to lkml too later. Regards Refuse. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Thu, 25 Oct 2001, Sottek, Matthew J wrote: > Ok, I slightly modified the idea to take care of this too. I must > say, I really really like this one. > > #define XV_TOP_FIELD 0x01 > #define XV_BOTTOM_FIELD 0x02 > #define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) > #define XV_HOLD 0x04 > > Mostly the same behavior as before, but now we really use these as > bitfields. When the XV_HOLD bit is ON, the data is not updated > onscreen at the end of an XvShmPutImage. It has to wait until the > HOLD bit is removed. > Here is the change, Bits 0 and 1 indicate the fields that will be > updated with the next XvShmPutImage. The image position and scaling > information are always updated. Here are some example uses. > > Default Case: (Works just like it does now) > XV_FRAME_TYPE = XV_TOP_FIELD | XV_BOTTOM_FIELD (Default) > XvShmPutImage: Both fields are updated from the XvImage, the data > is updated asap onscreen since the HOLD bit is not on. > > Interlaced Video: > XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD | XV_BOTTOM_FIELD > XvShmPutImage: The top field and bottom field are updated from the > XvImage. The position, size and scaling information are updated > from the call, but the overlay is not updated onscreen. XV_TOP_FIELD | XV_BOTTOM_FIELD is redundant. You can't not copy both fields. > XV_FRAME_TYPE = XV_TOP_FIELD > The overlay is updated with the latest information and set to > show only the top field. The onscreen update happens asap. > XV_FRAME_TYPE = XV_BOTTOM_FIELD > The overlay is set to show the bottom field and the onscreen update > happens asap. > > Paused Video: > Loop: > XV_FRAME_TYPE = XV_HOLD > XvShmPutImage: NO Fields are updated from the XvImage, but the > position and scaling information are taken from the call. The > overlay is not updated onscreen. > XV_FRAME_TYPE = XV_TOP_FIELD > On Screen changed happen asap. > goto Loop This is confusing. I don't understand what you are trying to do here. Mark. > > Paused Video (Better way): > Loop: > XV_FRAME_TYPE = 0x0 > XvShmPutImage: NO Fields are updated from the XvImage, the position > and scaling information are updated. The HOLD bit is not set so > overlay is updated asap. This means that for a pause you just set > The frame type to 0 and continue with puts as normal. No data > copying takes place. > goto Loop > > > Field at a Time Interlaced: > XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD > XvShmPutImage: Only the top field is read from the XvImage. This is > done by taking the first line and then skipping every other line. > The position, size and scaling are updated from the call. > XV_FRAME_TYPE = XV_TOP_FIELD > Update on screen happens asap. > XV_FRAME_TYPE = XV_HOLD | XV_BOTTOM_FIELD > XvShmPutImage: Only the bottom field is read from the XvImage. > Position, size and scaling are updated but not onscreen. > XV_FRAME_TYPE = XV_BOTTOM_FIELD > Onscreen update happens asap. > Repeat. > > > -Matt > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
On Wed, 24 Oct 2001, Billy Biggs wrote: > > Note that this introduces some slight uncertainty in the display since > > the overlay might not correspond to the window location when it comes > > time to actually display. But that's not going to be a big deal since > > the times are short and you get a delay now anyhow due to the overlay > > not going into effect until the retrace on most hardware. It > > introduces a larger lag between overlay and image when moving windows > > which isn't going to be a big deal. You can't do this for blitted > > video though. The cliplist is stale by the time you display. Not a > > problem though since blitted video are merely fallbacks. > > So, this breaks when we're paused or showing a still and you move the > image around. Ugh. Are you sure this can't be handled in the hardware > without the client having to do another put? Or do you expect the > client to re-put whenever it moves (which it has to now anyways)? It's up to the driver. The driver can have Xv track window positions. That's what the RePut functions in the Xv->driver interface are for. But using this means that you always have to copy all the data to offscreen and not just the part that is displayed because different parts may be visible when you move the window around. That makes display in Xinerama prohibitory which is why I never use that interface in any of my drivers. In Xinerama, each card only copies the part it is displaying rather than copying the whole image. That, of course, means you can't continue to display when the window moves because you usually need data you haven't copied. To ensure that clients work with all implementations they should Put after window configure events. > > > > The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means that > > > apps using Xv without knowledge of this will just get a flip when > > > they do an XvShmPutImage. > > Matt you rock my world. Just reset this back to 0x3 when any client > releases the port. :) The driver doesn't see port releases. This would have to be a write-only attribute that applies to the next Put in the case of HOLD, or to whatever valid data the driver still has in offscreen memory (if it exists) for the display. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
On Thu, 25 Oct 2001, Sottek, Matthew J wrote: > >You can't do this for blitted video though. The cliplist is stale > >by the time you display. Not a problem though since blitted video > >are merely fallbacks. > > Why not? Use two offscreen buffers to hold the data and blit the > correct one over when the HOLD bit gets unset. Can't you check > the cliplist at the time when the bit is removed? We don't know how to get the cliplist. Drawable specific information is lost by the time you get into the driver. Xv passed you the cliplist explicitly during the put that represented a snapshot at the time the request was made. Once you leave your Put function the cliplist is stale. The very next request may have moved the window. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]I can make it! SIS630 under Mandrake
On Thu, 25 Oct 2001 17:11:10 +0100 <[EMAIL PROTECTED]> wrote: > Hello!! > I'm bougth a laptop from Airis and there is a sis630, and i just can't > make XFree rigth. I've try mandrake80 and mandrake81. > > I try a long list of solutions that i find in net. but nothing work. > > IS XFree4.1 the solution? > > What XFconfig? > > If anyone can help me. Please do it. We know that newer revisions of the SIS 630 chip have to be programmed in a different way. See http://www.rene.rebe.myokay.net/sis630/index.html for some info. We are workin on it - and I'll update this web-page soon, too. > Thank you. > RMFonse > > > __ > http://www.IOL.pt > Todo o mundo passa por aqui! > > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) eMail:[EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.rene.rebe.myokay.net/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI r128 pro with 32bits colors: working ?
Hi! i have an ati all in wonder 128 pro which is working well with 24 bits/pixel. 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? and in the future ? thanks for help stef ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Wrong colors in Xv using Trident 9540 (Cyberblade e4/128)
Dear all, I am running the current CVS version of XFree86 on my laptop equipped with the Trident Cyberblade e4/128 chip, and I have the following problem with the Xv extension: the colors seem to be wrong. The luminance seems to be right, but the colors are mixed up. Booting different kernels, or maybe simply power cycling the computer seems to give a new mix, although I haven't seen any consistent pattern. Any ideas? /M ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]I can make it! SIS630 under Mandrake
Hello!! I'm bougth a laptop from Airis and there is a sis630, and i just can't make XFree rigth. I've try mandrake80 and mandrake81. I try a long list of solutions that i find in net. but nothing work. IS XFree4.1 the solution? What XFconfig? If anyone can help me. Please do it. Thank you. RMFonse __ http://www.IOL.pt Todo o mundo passa por aqui! ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert] Xv hit list
> Note that this introduces some slight uncertainty in the > display since the overlay might not correspond to the window > location when it comes time to actually display. But that's > not going to be a big deal since the times are short and you > get a delay now anyhow due to the overlay not going into effect > until the retrace on most hardware. It introduces a larger lag > between overlay and image when moving windows which isn't going > to be a big deal. Right, that delay isn't going to have much of an impact. >You can't do this for blitted video though. The cliplist is stale >by the time you display. Not a problem though since blitted video >are merely fallbacks. Why not? Use two offscreen buffers to hold the data and blit the correct one over when the HOLD bit gets unset. Can't you check the cliplist at the time when the bit is removed? > So, this breaks when we're paused or showing a still and you move > the image around. Ugh. Are you sure this can't be handled in the > hardware without the client having to do another put? Or do you > expect the client to re-put whenever it moves (which it has to > now anyways)? Ok, I slightly modified the idea to take care of this too. I must say, I really really like this one. #define XV_TOP_FIELD 0x01 #define XV_BOTTOM_FIELD 0x02 #define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) #define XV_HOLD 0x04 Mostly the same behavior as before, but now we really use these as bitfields. When the XV_HOLD bit is ON, the data is not updated onscreen at the end of an XvShmPutImage. It has to wait until the HOLD bit is removed. Here is the change, Bits 0 and 1 indicate the fields that will be updated with the next XvShmPutImage. The image position and scaling information are always updated. Here are some example uses. Default Case: (Works just like it does now) XV_FRAME_TYPE = XV_TOP_FIELD | XV_BOTTOM_FIELD (Default) XvShmPutImage: Both fields are updated from the XvImage, the data is updated asap onscreen since the HOLD bit is not on. Interlaced Video: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD | XV_BOTTOM_FIELD XvShmPutImage: The top field and bottom field are updated from the XvImage. The position, size and scaling information are updated from the call, but the overlay is not updated onscreen. XV_FRAME_TYPE = XV_TOP_FIELD The overlay is updated with the latest information and set to show only the top field. The onscreen update happens asap. XV_FRAME_TYPE = XV_BOTTOM_FIELD The overlay is set to show the bottom field and the onscreen update happens asap. Paused Video: Loop: XV_FRAME_TYPE = XV_HOLD XvShmPutImage: NO Fields are updated from the XvImage, but the position and scaling information are taken from the call. The overlay is not updated onscreen. XV_FRAME_TYPE = XV_TOP_FIELD On Screen changed happen asap. goto Loop Paused Video (Better way): Loop: XV_FRAME_TYPE = 0x0 XvShmPutImage: NO Fields are updated from the XvImage, the position and scaling information are updated. The HOLD bit is not set so overlay is updated asap. This means that for a pause you just set The frame type to 0 and continue with puts as normal. No data copying takes place. goto Loop Field at a Time Interlaced: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD XvShmPutImage: Only the top field is read from the XvImage. This is done by taking the first line and then skipping every other line. The position, size and scaling are updated from the call. XV_FRAME_TYPE = XV_TOP_FIELD Update on screen happens asap. XV_FRAME_TYPE = XV_HOLD | XV_BOTTOM_FIELD XvShmPutImage: Only the bottom field is read from the XvImage. Position, size and scaling are updated but not onscreen. XV_FRAME_TYPE = XV_BOTTOM_FIELD Onscreen update happens asap. Repeat. -Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]White Box Cusor
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Greg Ward > Sent: Thursday, October 25, 2001 10:21 AM > To: Steven L. Sesar > Cc: [EMAIL PROTECTED] > Subject: Re: [Xpert]White Box Cusor > > > On 25 October 2001, Steven L. Sesar said: > > My problem is with XFree86 4.1.0-7. After reconfiguring, reinstalling, > > recreating XF86Config-4, and adding Option "SWCursor" to my > XF86Config-4 > > file, I cannot get rid of this white box for a cursor. Which > sort of works, > > btw. > [...] > > Section "Device" > > Identifier "Matrox G200" > > Driver "mga" > > Option "UseFBDev" "true" > > VideoRam8192 > > Option "SWCursor" > > EndSection > > I have the same problem with with a G400, but only when UseFBDev is > true. If I set that to false, the cursor works OK. I didn't try > setting SWCursor because I didn't know what the option was called, and I > didn't bother looking for it. > > Greg Option "hw cursor" "off" should work better (or maybe it's hwcursor) Randall > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]White Box Cusor
On 25 October 2001, Steven L. Sesar said: > My problem is with XFree86 4.1.0-7. After reconfiguring, reinstalling, > recreating XF86Config-4, and adding Option "SWCursor" to my XF86Config-4 > file, I cannot get rid of this white box for a cursor. Which sort of works, > btw. [...] > Section "Device" > Identifier "Matrox G200" > Driver "mga" > Option "UseFBDev" "true" > VideoRam8192 > Option "SWCursor" > EndSection I have the same problem with with a G400, but only when UseFBDev is true. If I set that to false, the cursor works OK. I didn't try setting SWCursor because I didn't know what the option was called, and I didn't bother looking for it. Greg ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Last review of xfree86.
Does the 4.1.0-3 rpm that comes with 7.2 have any support for the AIW drivers that are at gatos? Chris On Wed, 2001-10-24 at 07:01, Mike A. Harris wrote: > On Wed, 24 Oct 2001, Hanyo Vera Anders wrote: > > >I am trying to install redhat 7.1 in a notebook with a mobility radeon > >graphic card, but I cannot do it with the last released version of xfree86 > >(version 4.1.0). > > That card is not supported on Red Hat Linux 7.1. Our just > released Red Hat Linux 7.2 has some preliminary support > graciously donated by ATI, which is also in the CVS head. > > The Radeon Mobility support in 4.1.0-3 is untested, so I do not > know how stable or functional it is. > > > >I know that if I want to get the very last version, I have to download > >version 4.1.0 and make a CVS check of it, but I don´t have an ethernet > >connection and it takes ages. > > Yes, the latest drivers for this card will appear in XFree86 > 4.2.0. > > >Does somebody knows of some other way to get the very last version ? Is it > >any ftp site where I could download the very last version without making a > >CVS check ? > > Aside from using CVS, you might try a search engine, or something > like rpmfind.net. Someone out there I believe makes daily > snapshots available. I plan on making Red Hat packaged daily or > semi-daily snapshots available in the future also - but no ETA > yet. > > Hope this info helps. > > Good luck, > TTYL > > > -- > Mike A. Harris Shipping/mailing address: > OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, > XFree86 maintainer Ontario, Canada, P6C 5B3 > Red Hat Inc.Phone: (705)949-2136 > http://www.redhat.com ftp://people.redhat.com/mharris > Red Hat XFree86 mailing list: [EMAIL PROTECTED] > General open IRC discussion:#xfree86 on irc.openprojects.org > -- > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Dual Monitor (single or dual card?)
Hi, We are going to update a computer to run some special software that works on Linux, and we are going to install Mandrake 8.1 or Red Hat 7.2 (What do you recommend?) The point is we actually own a Colorgraphic video card and we want to put it on multiscreen and/or multihead (multiscreen=xinerama). If not, we want to buy 2 cards or a dual head card, like a Matrox G450. Any tips or recommendations? Colorgraphic cards are dual Cirrus Logic. Thanks a lot. David. PS: Please send responses with copy to my email too.
