Re: Manufacturers who fully disclosed specifications for agp cards?
- Original Message - From: netpython [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 9:38 AM Subject: *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: Manufacturers who fully disclosed specifications for agp cards? [...] (reverse engineering) Are there any good tools to do that under linux ? there are a few dis-assemblers and debuggers around for Linux, but the most promising approach to my understanding is the emulation approach. there are projects which do make run e.g. windows printer drivers on Linux via emulation (e.g. Wine), other driver models will follow that soon and then you should have full abilities on intercepting nearly anything what goes on. lets consider even the newly announced coLinux (@sf.net) approach as some basic approach for an emulation platform. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** GMX Spamverdacht *** Re: Manufacturers who fully disclosed specifications for agp cards?
Subject: *** GMX Spamverdacht *** Re: Manufacturers who fully disclosed It is possible to gain the specs for a chip by discetion for i.e R300 chip or NV 30 chips with the right tools like a electon microscope? full specifications as the headline does say is more than just the register description, and still much more than the register specs plus an in deep descriptions of internal logic in text and diagrams. it is further the electrical, thermal, mechanical and other related specifications - you dont need all those documentation when just wanting to program such a circuit for a limited purpose. an REM device is of course a good tool for finding out a bit more about the internals of such a device. i just dont have it to my hands. other than that, reverse engineering can be helpfull in some cases. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon 9700 question - need working config
tryout the closed source drivers from ATI´s website. if you find out about any problem then call either ATI or SuSE support on them. they must have a solution. -Alex. - Original Message - From: William W. Austin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 28, 2003 11:47 PM Subject: Help: radeon 9700 question - need working config Apologies in advance for this, but I've been pulling my hair out for hours on this one. My nephew (lives several hundred miles away) wanted to install linux on his formerly win-xp machine (athlon 2800 xp, 512 MB, 2 large drives, etc.) with Radeon 9700 Pro (128 MB) video card. He went out and bought Suse 9 and did a completely clean install (with me on the other end of the phone line the whole time - he's new to anything not from MS). Everything installed cleanly and the machine booted successfully, HOWEVER: The video card is not recognized. It is a Radeon 9700 Pro with 128 Mb of memory (AGP) and works correctly under the other OS, but although it shows up in scanpci and lspci, the setup utility on Suse bombs and cannot set up the card. He is also singularly unable to run a simple command (rpm -q XFree86) to tell me the version on that machine - and I haven't been able to get the info from any Suse website (and his net access is temporarily down until school starts again in January). I've spent nearly the entire day (11 hours) with him on the phone trying to find a solution but I nave other cards - no radeons - and my config files don't help here). XFre86 -configure fails, unable to find the device. If anyone has a working XF86Config file they can email me, I'd greatly appreciate it (as a last effort before I tell him to turn off linux until I can go visit him in 3 weeks). I'm going out of town and he is nearly desparate to get X up and running on this machine. Please feel free to mail me privately if you can help. Thanks and apologies for wasting the bandwidth. Bill Austin -- William W. Austin [EMAIL PROTECTED] [EMAIL PROTECTED] Life is just a phase I'm going through... ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: State of radeon driver
the _ is the mailmain default but can be canged. only the fglrx closed source drivers from ATI for the i386/Linux platform do have 3D. Databooks are no longer state of the art in the information technologies age. On Wednesday 10 December 2003 12:48, wim delvaux wrote: Any idea whether what support 4.4.0 will have from the Radeo 9600 Pro ? And now in English ;-( Any idea what support 4.4.0 will have for the Radeo 9600 Pro ? ATI haven't released any databooks about newer GPUs like R300 R350, so there's currently no 3D acceleration for these cards (9600, 9800 etc) yet. To the administrator; could the separator above the Devel mailing list be changed to be only -- , so that quoting when replying automatically removes that signature, when using compliant mailers. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: State of radeon driver
I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
I suppose I could have a hardware problem, since my PC is a couple years old now. However, I can leave the same computer just running a 2.4.x kernel for days with no problems. Would the redesigned kernel 2.6.x bang the hardware so much more; going beyond that of kernel 2.4.x? It can be that a new kernel does make use of resources that were previousely ignored. in the past e.g. turning on fast writes on the AGP bus lead several systems to instable behaviour - the chipset claimed it supports that but when enabling this it all turned out to be of questionable use. maybe there is just a power save flaw, a problem with IRQ coding or something else that hits the system at a rather sporadic rate - it is hard to say what it is. sometimes only an analysis with quite advanced hard and software tools can shed a light on the root cause. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Radeon 920, hardware 3D
I always get these errormessage when I load agpgart and fglrx and then startx. The weird thing is that X starts up with this gray screen and the mouse working. It only crashes the instant when the KDE dialog should be coming up. (==) Using config file: /etc/X11/XF86Config-4 (WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found Could not init font path element /usr/X11R6/lib/X11/fonts/local/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from list! DCOP aborting call from 'anonymous-3627' to 'kded' ERROR: KUniqueApplication: DCOP communication error! DCOP aborting call from 'anonymous-3630' to 'knotify' ERROR: KUniqueApplication: DCOP communication error! startkde: Shutting down... looks to me like your KDE install is somewhat corrupted. how about a totally pure and simple XFree86? this will launch an X-Server without any window manager. shut it down with CTRL-ALT-Backspace if the mouse moves. other attempt, try fvwm2, twm or GNOME window manager. it should be configureable by your system software or via hidden files at your user's home directory. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Radeon 920, hardware 3D
run ldd on your glxgears or glxinfo executables and see which libGL it is using. It is using the ones from the driver. It uses libGL which points to a link which is the drvier lib. I made a diff on the file which is in the driver directory and the installed libGL.so.1.2 and they are the same. diff does not work on binary files, you better compare the file sizes. i dont have to doubt, ldd must resolve the active files all the time. When I run glxgears I get now 300FPS which is a little better because previously I had 99FPS but I think that was because I was using sync to vert retrace. the 2nd is a reasonable effect. the first case should have some 2.000 fps or more, i think its software. try re-running glxgears with settings LIBGL_VERBOSE=1 and LIBGL_DEBUG=1 in the hosting shell, somtimes that gives some more hint. when I run enemy territory it always claims that I'm using Mesa, though I don't know why it thinks this. I already uninstalled Mesa, so there shouldn't be any files there. depends on distor and setup, sometimes there are standalone Mesa packages and other times it is all merged into the XF86 libGL packages as the non-optional sofware renderer fallback. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
I tried just leaving the display running without doing anything interactive with the interface and X ran for several hours before freezing. All that was running was Xscreensaver. I then tried again using X normally but with a different window manager (XFCE 4) and it worked for about an hour and then froze again. having a machine frozen after several hours could mean a thermal problem. this can inlcude even overclocked CPUs or instable RAM or anything else on the bus or the grafics. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
SPLIT_WC_REGIONS - anyone out there?
Hello, i stumbled across the above mentioned define and related code in the XFree86 sources (lnx_video.c). comparing X4.1.0 and X4.3.0 i found that the condtitnal coding of if (base % size) has vanished at some point in time and the handling is now hardcoded at this code location. to my best knowledge that coding is related to maybe the 3Dfx PCI memory regions layout with a single mixed framebuffer and register mapping. is any developer out there that is willing to describe the main points of that design in a few words. i am asking for that because i have had a case where the split code went into action despite any need and even the PCI range was a power of two. so in theory it should not happen. before popping up with any general solution i just wanted to make sure that i got the right idea of that code. to my understanding current mtrr implementations might be more flexible than it is assumed in the existing code. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: ansifying xwininfo.c
This is the minimum work to get this program into ansi shape. This patch is ready for inclusion. If their are no objections to the patch, it would be very nice to get this in ASAP. It will make some other projects I am working on go smoother. Thanks, Warren Turkal i have no reason to object to such patches. it was done in 100 kB sized tarballs for the XFree86 tree in the past and worked well that way. having such extern statements in a single header file is a major point of getting interfaces verfied on any platform at compile time (if the compiler is not tuned to react like dead beef). compilers like the intel c for linux do even provide switches to make functions either static or requiering an extern prototype thus giving you no choice to miss any indecisive variant. go on with such things, you will be suprised how many points for improvment you can find even without any big sense for the project as a whole. thise could be a simple entry point for future dri coders. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: 2 questions about radeon driver
CP mode means using an engine on the chip that gets the command data from main memory by itselves, some sort of busmaster DMA stream. MMIO means that the driver does program the chipset directly via its memory mapped registers. DRI means direct rendering and is the most common socket for current OpenGL implementation upon some kernel module supplied and shared resources. XAA is the 2D accelleration which can be done either in MMIO (helps quite a lot for bring up) or CP mode - it might make use of some kernel module supplied resources in CP mode. But there is no need or requirement that DRI is exposed in that mode, only the other way round if you are having DRI then its highly likely to have the XAA running in CP mode as well. therefore presence of HW accellerated OpenGL does indicate that the XAA is as well running in CP mode. If you need to know hos the XAA is operating then you should hook into the driver. its not common to let external applications know or even assume either state because they are outside of the 2D display driver. let me assume you are trying something that does go byond the concept - either you implement Xv functionality inside or close to the 2D driver or you are asking for heavy trouble. -Alex. -Original Message- From: Alex Deucher [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 21:50 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 2 questions about radeon driver I have two questions for you about the radeon driver. the first relates to the CP and accel. I'm attempting to convert the Xv code to use the CP. how do you check to find out if the driver is using CP or MMIO accel? I considered using info-directRenderingEnabled, but as far as I can see the radeon can use the CP for accel even if the DRI is disabled. It's probably obvious, I'm just missing it. secondly, is there a way we could switch to software rendering if the total width or height of or all rendering windows is larger than 2048? Since we seem to be hw limited by that, it'd be nice if the driver would just switch to software after 2048 rather than just showing a blank window or in some cases locking up the video card. It might be too much of a pain in the butt though... thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Driver problem for RADEON 9100
(WW) RADEON(0): monitor1: Using default hsync range of 28.00-33.00kHz (WW) RADEON(0): monitor1: using default vrefresh range of 43.00-72.00Hz (II) RADEON(0): Clock range: 20.00 to 350.00 MHz (II) RADEON(0): Not using default mode 800x600 (hsync out of range) (II) RADEON(0): Not using mode 800x600 (no mode of this name) (--) RADEON(0): Virtual size is 640x480 (pitch 640) (**) RADEON(0): *Mode 800x600 (**) RADEON(0): *Default mode 640x480: 25.2 MHz, 31.5 kHz, 60.0 Hz (II) RADEON(0): Modeline 640x480 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (II) RADEON(0): Valid Clone Mode: 640x480 (II) RADEON(0): Total of 1 clone modes found (II) RADEON(0): Total number of valid DDC mode(s) found: 0 (WW) RADEON(0): Mode 800x600 is out of range. (WW) RADEON(0): Valid modes must be between 320x200-0x0 (WW) RADEON(0): Mode 640x480 is out of range. (WW) RADEON(0): Valid modes must be between 320x200-0x0 (II) RADEON(0): Total number of valid FP mode(s) found: 0 (EE) RADEON(0): No valid mode found for this DFP/LCD (EE) Screen(s) found, but none have a usable configuration. Let me say, there must be some driver problem. I think the major problem for setting up a cloned LCD/DFP mode is the lack of DDC detected modes for the 2nd port, so the driver is unable to clone any mode at all. i would like to pass that on to the experts. i dont know if using a snapshot version of the drivers or of X11 will help in any way. -Original Message- From: ddeki [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 17:50 To: [EMAIL PROTECTED] Subject: [XFree86] Driver problem for RADEON 9100 Hi I have a problem whit drivers for my graphic card RADEON 9100, I tray whit ati and radeon drivers and still is the same problem. The config and log file is attached. Thanks Dejan Bogoevski Macedonia [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: radeonfb in 2.6.0-test2 and radeon 320m
I have laptop with 320m radeon. radeonfb didn't seem to work for it on 2.4.21. Has this changed in 2.6.0-test2? this is the XF86 development mailing list for the XF86 windowing system infrastructure. there are other people around that do work on the framebuffer device support. you might ask them in the first row. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Seeking MergedFB - Xinerama development advice
just a short comment on the illustrations... Mode 1: (fixed width font required for viewing) +--+ |++ +-+| ||| | || ||| | || ||| | head 2 || ||| |1024x768 || || head 1| | || ||1280x1024 | | || ||| +-+| |||| ||| Virtual framebuffer| |++| +--+ bottom right part is not virtual, it is just a true framebuffer memory region that is not feed to any RAM-DAC unit. virtual means more sort of emulated or not really what it seems to be. it makes only sens if you attribute the virtual word to desktop or screen and thus to the whole area, making up a virtual desktop or virtual screen support in contrast to the possibly much smaller true viewport areas. in the view of the CPU and the GPU it is frambuffer, regardless how you can view it. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: via driver and mtrr problem
I'm running XFree 4.3.99.8 with kernel 2.6.0.test2 on a via M1 motherboard. I loaded the modules for mtrr, i2c and agpgart for via. Into XF86Config I choose via driver When I start X there's always this warning: (WW) via(0): Failed to set up write-combining range (0x I tried with less /proc/mtrr and it gives back correct values, at least they seem reasonable but I can write them down. Anyway X seems to run fine, so what problems may I expect to encounter? i cant say what direct reaction your software setup will perform on mtrr setup failurs. mtrrs are programmed to achive specific cache flushing behaviour and increased performance, especially as framebuffer writes and maybe for AGP mapped memory access as well. if mtrr fails, the performance might be sub optimal or you might spot (in worst case) hangs due to inadequate cache flushing. for tracking that down you might need to understand your chipset and the respective mtrr allocation code in the linux kernel. i dont want to say that code is bogus, but i have seen that it does react somewhat non logical in a few cases, so there might be a need for deeper inspection at some point in time. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Hardware overlays (8+24?) on Intel i830
mobile devices will always have more limitations, so you wont get rid of any sort of low bpp formats. in multi buffer environments, such as OGL with front, back, depth, stencil, overlay, whatever you will be in need to deal with any sort of pixel depth at the same time as well. for imaging programs there are alpha planes, some are even only 1 bit per pixel, so thats another case where X11 might need to support it for a long time. -Alex. -Original Message- From: Matthew Tippett [mailto:[EMAIL PROTECTED] Sent: Friday, July 25, 2003 17:34 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Hardware overlays (8+24?) on Intel i830 It is very useful when dealing with programs of a 5-10 year vintage that were originally developed under X-Windows when 8 bit displays were the best you could get. Since most 8 bit displays used PseudoColor (read Pallete based), they have particular hard-coded logic to deal with the color map. Almost all modern hardware is capable of 24 bit without breaking a sweat (or the memory limit), so modern programs probably just assume TrueColor. So as Linux continues it's into the Enterprise and companies find new life for their old Unix applications that can now run on desktops and laptops running Linux, I would expect that this will become a required feature for Enterprise class drivers. Luckily XFree86 already has support for mixed visuals with a number of drivers. Regards, Matthew Sottek, Matthew J wrote: Yes, The Mobile chipsets could do this under several circumstances. The desktop chips cannot. Could you provide an indication of what such a feature is actually useful for? It seems like more of a toy feature than something with real world applications. Seems like you could actually run at 24bpp and convert from 8 to 24 in the driver with less performance impact than running an additional display plane that consumes width*height*depth*refresh bytes per second guaranteed. -Matt -Original Message- From: Dr Andrew C Aitchison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 5:09 AM To: [EMAIL PROTECTED] Subject: Hardware overlays (8+24?) on Intel i830 I see from http://www.xig.com/Pages/PrReleases/PRMay03-830-O'lays.pdf that hardware overlays (possibly similar to what we currently do in the mga and glint drivers) are possible on the Intel i830 chipset. Does anyone know anything more, or is anyone actually working on adding support to our drivers ? If anyone with a suitable machine is interested in testing for me, and I can get chip-level details, I *might* be interested in writing the code myself. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: patch procedure ..
from 24 hours to 7 days depending on complexity and on people having time working on it. -Alex. -Original Message- From: Sven Goethel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 19:17 To: [EMAIL PROTECTED] Subject: patch procedure .. sorry for being lazy and not RTFM, but after i send a patch to the patch email addy, and i have received an acknowledge .. - how long does it takes to get an answer - usually - will it happen to get no answer at all ? thx for any reply sven ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Rant (was Re: ATI Drivers.)
On Fri, 18 Jul 2003, Mark Vojkovich wrote: For consumer desktop that's true. There is one potential business case in the professional desktop market. SGI's, HP's and Sun's old workstation customers have been moving over to Linux. Thats no market secret to anyone at all. You just have to browse for the leading application software vendors and then admit that any big tool in the digital content creation business is availabel in a Linux port as well. Lets say non of the PC big vendors want to miss those business and therefore would run havoc if their requirements to grafics vendors for their hardware and drivers would lack the Linux OS support. Obviousely the intel compatible PC architecture is the toy of choice. All the film studios are using Linux, for instance. The volume is small but the margins on the professional cards is high so there is a chance that it might actually make money some day. If it weren't for this potential in the professional market, NVIDIA probably wouldn't have any binary Linux drivers. The real target of those drivers is the NVIDIA Quadro line not the GeForce line. or alternatively an ATI FireGL board but not the ATI Radeon. its the same market situation for them so there cant be much difference. whoever looks back on the driver history can easily verify this sort of reasoning the driver bring up. From: Fred Heitkamp [mailto:[EMAIL PROTECTED] If the server market is the biggest (and for Linux it is) then only 2D support if that is required. I'd bet even the big film studios don't use Linux to view the final rendering. They probably use a Mac (Apple OS of some kind) or a PC running Windows. It is NOT the server market, it is the grafics render farming and the related grafics editing at the desks of the movie industry. Ehm, why should movie industry not use all in the same OS flavour when they know that it pays out for them. And admin is much luckier when anything behaves the same instead of having a multi OS installation. A department must have strong needs to convince an Admin to make such sort of an excemption, or it must cancel any calls to the IT admin if it installs that system without his explicit approval. Hey, what do you think how final film rendering is done for digial movie industry? They do have the films on some sort of fast and high volume media in order to provide a high quality result. Such digital data is best stored on SCSI-RAID systems with bus adapters that grant the needed troughput. Maybe even some two or three of 64 bit PCI adapters are needed and a RAID array with some 5 to 8 disks, each with 100 GB volume, per adapter. -- I have seen Windows administrators going mad when they just started putting a 2nd SCSI controller into the same PC. Linux simply does it and comes with RAID for no cost. Then there must be some core unit, possibly a long term established 64 bit CPU or whatever 32 bit i686 design is capable of managing the system data flow fast enough. -- I am not really aware of Windows supporting anything but the i686 at high speeds, so there is an important limit on choices. Linux supports nearly any sort of speedy CPU, so its a nice guy. Goint to grafics, there might be even enoug bus transfer performance for the good old Hercules Dynamite 128, but of course some current boards might perform better. Its just that movie creation devices might need fine tuned video modes in color depth and resolution. Possibly the adaption to 10 bits or 12 bits per component formats is simpler if the system can be freely programmed. -- Windows does not let you tweak video modes that much. Linux offers open source and lets you customize nearly anything. Such a box must use a nearly invisible system activity footprint to not intercept any of the time critical movie data streaming. Further a windowing system is not really needed whilst streaming, its enough if the framebuffer gets initialized and some sort of remote hardware control for the image engraving is doable. -- Windows comes with a quite heavy memory foot print and a big bunch of running threads, even when in rescue console mode. Its uncertain how viable that console is for possbily multi cpu operation or whatever feature you might need for the project. You do need a big bunch of costly tools to write Windows drivers, even if you only want to access a certain IO-Port. Linux is easily reducible to some 100 kB of kernel with only the components in there that are really urgently needed. You have quite a number of choices how to operate your grafics. If you thinkg you do want some IO-Port access, then just patch it. In the end - why setup such a machine with something you cant control whilst you have anythin you need to your hands at no cost and tested on your remaining infrastructure? Thats the considerations that are attaching to a current film rendering system project. There might have been prior
RE: Rant (was Re: ATI Drivers.)
From: William Suetholz [mailto:[EMAIL PROTECTED] Mr. Harris, yes I am one of Those people who want a device to work in my chosen operating system, /me wants Commodore 64 - BASIC BIOS 2.0 support, call it my favorite! Cool machine, boots in 2 seconds to a fully useable prompt. It must be an important platform therefore. Really, i dont lie. and have been frustrated that while things have gotten a bit better than they were in 1998, the OS and users that use it are still considered second class by the device manufactureres despite some very quiet lip service on the manufacturers part. Nope, its rather Win XP, Win 2000, Win ME, Win 9x, Win NT 4.0 and then comes the Apple platform. I dont want to count, but since my C64 was sold more than a million units i think its more important than your platform. *guessing* I still am not able to use the DVD playback acceleration features, because the chopped that out of the docs. Then it must be something that is called intellectual property that those vendor dont want to expose to other parties since it is either valueable by its design or a unit with rights pending from others that have charged money for giving it away on a per unit base or other license sheme. I dont know. Not entirely true.. I have gotten support from ATI in getting their stuff to work under NT and other MS systems. Seems their sales do include a support fee for the meintioned platform. But they cant charge you a support fee for already sold boards. Or can you give me an idea how that could work? On the other hand.. If more people who didn't want to have to run another OS to access features that are not well supported because of lack of knowledge on how to support them would comment/complain (oh alright -BITCH-) maybe the hardware vendors would realize that there is a viable market for their devices to be used on the second class OS's Hmm, someone else explained quite interestingly why a 1000:1 number of users is a good reason for considering them as an UN-important amount. And, I'm sure that ATI has a file on me :-) I've been commenting on this directly to them for some time. Lets see how long it takes to accumulate enough for such comments to improve the situation to your total pleasence. Its only the very last resort of DVD decoding accelleartion support, got it right? Yes I am a random person, and, I'm a nobody who must be a pretty terrible person to want to use something other than a MS supported product to utilize the features that the card was purchased for. And, I must never (in the 5-7 years I've been asking for this) have thought about the business side of things. You know its the vendors decision what he providew with the product. And it was your decision to accept that product for your targets. Maybe there was really no better choice at that moment for you. But you got miscs commitments over the years which significantly did improve your situation - there was really no strong base (like a sales promise) for that vendor that urged him to perform like that. I would call that a rather friendly act or better a gift. Didnt you like that sort of gift? Would you be happier if its withdrawn? I would actually be satisfied with Binary only drivers that would support the whole card. But, there aren't enough people letting them know that there is an interest (OOPS that would be BITCHING!). Its becoming nearly a habit for you. *gg* Dont you think the OpenSource programmers could understand that sort of speech in a non friendly as well? i think they dont have problems in that sort of co-existance. its merely that some Linux users always switch between those two worlds all the time when in a bashing mood. XFree86 has an interest in the drivers that have been forked into other projects. And, the group has a working relationship with the vendors in question, which means that such concerns can be expressed in places that will result in the best possible result. Rather than Random people (never call them customers) that use the vendors hardware can use the hardware in a manner befitting the quality of the hardware's design. If you do pay enough for it then you can have nearly anything. At least thats the idea that a comercial facility does work. As there is not that much money involved in OpenSource there is a basic problem in interacting with such facilities. Other developers have expressed at some time that they got best results of responseness in cases where the money factor did not hit big into a case. This means if either it was a relatively small effort compared to the other operations or in cases where the copmany already knew that there was no chance to get any more money from a specific still alive component and so had no more reason to hide anything. One thing, you might know that companies with no longer existing business tend to behave like they are no longer existing - having no money does mean there is no
RE: RH9 Display Settings Card List
From: Mike A. Harris [mailto:[EMAIL PROTECTED] I plan on replacing the Cards database in Red Hat Linux with a new mechanism sometime in the future which will be much more flexible, allow per architecture overrides, allow the config tool to know what hardware supports DRI and on what specific architectures, and other useful things that are desperately needed. This would also allow drop in drivers to also drop in new database files which could supplement the database that comes with the OS, or override specific entries, or allow multiple drivers to be alternatives for a particular card. Mike A. Harris Mike, it would then be nice if those helper files will be split on a per vendor or better on a per driver sheme. At least for maintainance and on needs for a special tweaking that will help people a lot. Maybe that should be split up on a per CPU or platform base to reduce the amount of date for a specific platform. just a few suggestions - there might be better ideas around. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Getting Dual Independent Heads to work on Debian(sid) on iBook
I dont really know driver or chipset in detail, but its the way that it needs programming so that the timing for the LCD does match. black or striped or whatever effects do indcate wront timing for the flat pane display. If the device is capable of dual head in other OS condtions then it can do it with Linux as well. Current AGP grafics chipsets in PCs do expose device 1:0:0 and 1:0:1 with different IDs (on AMD boards the 2nd number is higher). for real programming the first is preferable. in other words the driver must be capable of doing two outputs in parallel or it will only drive both outputs with identical timings and same contents. its a single graphics core and does need at least one output unit programmed. if neither of the driver does know about the other then there is a serious problem because they will heavily fight for the same output timing registers. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
portability of function prototypes?
i am seeing constructs like this at
several locations of the XFree86 sources:
*.h:
extern char *Xpermalloc(
#if NeedFunctionPrototypes
unsingend int /* size */
#endif
);
*.c:
char *Xpermalloc(unsigned int length)
{ ... }
#if NeedFunctionPrototypes
XrmQuark XrmStringToQuark(
_Xconst char *name)
#else
XrmQuark XrmStringToQuark(name)
XrmString name;
#endif
{ ... }
for my impression the applied macro check
is obsolete nowadays and should not used
any longer for current coding. the phrase
inside the first #if #endif is a needed one.
i think for the second one the if-case is
probably the prefered coding style whilst
the else-case is the obsolete coding style.
am i right? this is a pure leftover?
or am i wrong and some targets do still
have some heavy dependencys on that?
are there some coding guidlines somewhere
in the tree that do outline on that subject?
i am personally targetting on compatible
coding and avoiding breakage of other codes.
-Alex.
PS: i am hoping for a response of some long term
XFree86 developer to answer this.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RE: patch to make 4.3.0 build on FreeBSD 5.0-Current alpha
[snipped the patch] Is there a better way to submit patches like this? I've just subscribed to the devel list in the last 10 minutes :). Fred Clift sending to [EMAIL PROTECTED] queues your patch for integration. maybe unified diffs are the prefered style (diff -u src dst). it improves readability due to included lead-in/out context. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: RELNOTES for 4.3.0
RandR integration with partial enable of features? -Original Message- From: Alan Hourihane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:15 To: [EMAIL PROTECTED] Subject: RELNOTES for 4.3.0 Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Mesa 4.0.4 is included for OpenGL(tm) support. * AMD x86-64 support. * Support for OpenBSD/sparc64. * Major OS/2 support updates. * 2D Acceleration for the Trident CyberBladeXP/Ai1 chipsets * Intel 845G support for Xvideo, 2D and 3D. * nVidia GeForce 4 support * ATI Radeon 9x00 support for 2D and 3D excluding the 9500 and 9700 for 3D acceleration. (Need comments about M7,M9 support ) * Major SiS driver updates for some of the latest chipsets. Unfortunately the SiS 3D driver has had to be disabled. No one took up the challenge to port the driver to Mesa 4.x. * National Semiconductor SC1x00, GX1 and GX2 chipset support. * Indirect GLX acceleration for the MacOS X Xserver. * Rootless Xserver for Cygwin/XFree86 (experimental) * An Xcursor library for alpha blended and animated cursors. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: RELNOTES for 4.3.0
Gatos is focussing on video and TV playback, TV/video-in functionality and video capture. But they are _not_ focussed on 3D to my understanding. thanks for the link to the AIW Radeon 9700 comments. the text outlines that even gatos has not timeframe how their development will proceed. for my understanding its partly related to the limited personal time they do have for dealing with that device. (okay maybe its meant different, but thats how i read that.) -Alex. Gatos have acording to http://gatos.sourceforge.net/supported_cards.php recived document ans sample hardware from ATI. an Romanick wrote: Mark Cuss wrote: A quick question regarding the 9500 and 9700 series Radeons - is support for 3D acceleration planned? Eventually, someday, if ATI releases the relavent documentation and enough developers have the time to do the work. In the meantime, if you're on x86 Linux (or perhaps some BSD flavors that can use Linux binaries), ATI has a very nice binary-only driver. The problem right now is that, even if ATI released all of the documentation available for the chip, there's not enough people with enough time and the right skill sets to bring-up a 3D driver for a new chip. :( ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: controlling refresh rate of the graphics card
Alexander Stohr wrote: what about syncing to the vertical blank? some cards do provide you an interrupt handler for this. what is the vertical blank ? . do you know somewhere where I can get more information on this? www.opengl.org is of course some central place of accumulation. but i would recommend you to start with e.g. the glut demos from Mark Kilgard, which are a flock of several hundred of small an large test, animation and demontration programs. most impressive is the gle extrusion object library. i mean if you do run some 30% of those demos than you truely do know if that is what you are looking for. you might to want to watch out for the (David) Bucciarelli subdir, for olympic or for the ideas sample animation in the glut demos package. I am not using openGL just Xvideo stuff.. but even then, how do I know that I am calling glSwap() at the right time ? glSwap abstracts the waiting for vblank (vertical screen retrace) and therefore performs it by itselves. .. does OpenGL wait till it has finished outputting one screen before it loads up the buffer ? yes, it has two buffers, and those can be swapped automagically on excatly the end of every displayed frame, no tearing anymore. is this doable with XvShmPutImage(...) ? OpenGL has its own complete set of rendering functions. thats so because its a highly portable thing. more portable of course when using the GLUT library for opening and closing windows. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
glapi_x86.S glx86asm.py
Title: glapi_x86.S glx86asm.py according to its headline glapi_x86.S was generated by the script glx86asm.py - its just that i cannot find that script in the XFree86 sources. Any hints? -Alex.
RE: glapi_x86.S glx86asm.py
You'd have to ask Brian to be sure, but I believe the intention is that if the interface ever changes, a new .S file be generated in the Mesa tree and imported to the XFree86 DRI trees. There should never be a case where the .S file would change in XFree86 and not change in Mesa. agreed, a rational method of doing it. i just didnt remeber that libGL and Mesa implementation are maintained elsewhere and are merely contributed parts. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: controlling refresh rate of the graphics card
what about syncing to the vertical blank? some cards do provide you an interrupt handler for this. i mean if you want to do it with OpenGL in fullscreen anyways then you just have to use double buffered mode and call glSwap() anytimes you are done with rendering. if you want to do something more complex, like showing fast drawing, and dont care if you see intermediate images, such like looking into incomplete objects, then the single buffer mode might do the job. a copy of the whole framebuffer on an up-to date grafics adapter will happen (depending on resolution) some 500 times a second, that fast are those boards. and you can still draw in between. -Alex. PS: OpenGL has quite high performance for bitmaps, 2D drawing and fonts as well. of course any 3D runs fastest with it. watch out for the tons of Linux OpenGL screen savers... ;-) -Original Message- From: Tim Roberts [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 20:36 To: [EMAIL PROTECTED] Cc: Tim Roberts Subject: Re: controlling refresh rate of the graphics card On Thu, Jan 30, 2003 at 11:14:13PM +1100, etienne deleflie wrote: thanks for your reply. I'm not sure that we are talking about the same thing though. I want to be able to control the refresh rate programatically. for a piece of software used in live video performance. I dont know if my software is going to be spitting out 25 fps or 22.341 fps (depending on how much processing i am trying to do). so I want to make a call to the graphics card myself, to tell it to refresh exactly after each frame has been drawn. That kind of control is simply not possible. Graphics controllers run on a continuous clock, feeding pixels out in a continuous stream. Further, because of the way you specify the clock divisors to the clock generator PLLs, you generally cannot get more than 2 digits of accuracy anyway. No, you will need to adapt yourself to the graphics chip, not vice versa. You can do that in xvideo by using double-buffering, so that you're drawing into buffer 2 while buffer 1 is being displayed. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boeklheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: DRM module compile problem under FreeBSD 5.0
PCI-gart is a still developing component that is maintained in the XFree86 3D instable tree, which is better known as dri-devel project. you might have better chances when asking there. anyways, that far i do know about PCI-gart, it was under some rather vague development. there were more patches from outside poeple that really integrated in the end due to lack of hardware, software and whatever. but its stepping up now due to porting efforts and alikes. -Alex. The following files use M_WAITOK which is not defined anywhere in the xc tree in the HEAD branch: ati_pcigart.h drm_drv.h drm_scatter.h ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
