Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture The first two worked even worse (no image at all), so in the following I'll refer to the later two which produce exactly the same results. .../... Probelm 2) No matter what combination (dual or single head) the colors are always wrong. This is independent of the depth used (every time differently wrong colors of course). That is probably the SURFACE_CNTL problem. Problem 3) Shutting down X blanks both screens - i.e. the frame buffer is not correctly restored. This is somewhat painful since after closing X you can access the box via ssh only. Typical with offb, X doesn't properly restore the radeon state to offb graphics mode it seems. Other relevant info: kernel is 2.4.20-ben10 (the devel versions crash), frame buffer works only with video=ofonly. Can you tell me more about the crash ? The benh-devel rsync should work just fine on this config with more radeonfb fixes. Framebuffer should work too without video=ofonly. Can you try my latest devel kernel and tell me ? If it boots but with no framebuffer, can you try to capture the boot log to a file and send it to me. (Please, let's continue the kernel related discussion separately and offlist) The system is debian sid (up-to-date). The CVS version of XFree86 was compiled using gcc 3.2 on the same machine. I don't know who's working on the radeon driver, but any help would be appreciated. I'd be delighted to help to track all this further down if possible ... Cheers, Simon -- Benjamin Herrenschmidt [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: OpenGL + XvMC
It *may* not always be required. There have been GLX extensions in the past (see my first message in this thread) that worked that way. However, as we discussed earlier, this doesn't seem to work so well with MPEG video files. The main problem being that you don't get the frames exactly in order. You're stuck doing a copy either way. Why ? You have usually enough video/AGP/whatever texture memory to store multiple frames. I haven't looked at XvMc, but there is a difference between rendering frames and scheduling them for display, you render them to multiple buffers and schedule display when your next expected display frame is ready. I completely agree that it's a big waste to still have a copy in cases where the HW let you avoid it Ben. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SDK and drivers.
On Mon, Jun 02, 2003 at 04:28:46PM +0200, Egbert Eich wrote: Sven Luther writes: On Tue, Apr 22, 2003 at 11:58:03AM +0200, Egbert Eich wrote: Sven Luther writes: Hello, ... I have been trying to build the driver SDK thingy on both 4.3.0 and head, and it seems to be somewhat broken. In particular there are some missing files, which altough needed, are not part of the SDK, like the render includes for example. So, i looked at the whole stuff, and have been trying to fix this, but encountered that many driver missed declaring some of their file, which is a pain. Since the driver SDK is aimed mostly at building drivers, maybe listing all files as being part of the SDK in the Imakefile is not the most appropriate way of doing this, since mostly _all_ the files of the driver directory are really needed, and in fact my aim is to not use the drivers from the sdk, but the ones from the driver module just announced by Alan. I'm currently exploring a toatlly new SDK which takes advantage of driver modules. It doesn't even attempt to add drivers to the SDK, but it expects them to be dropped in from a separate tarball. Hello, I expect to be looking at the SDK stuff again nextly, and would like to know if you did advance some with this code since you wrote this ? No, unfortunately not. I've just returned from vacation and didn't have time to look at it any more. The next two weeks are pretty occupied with other things, too. No problem, i have been busy with other things too, and my motherboard died on saturday, so i could not do much work this WE. Also, would your new SDK still use a fixed path or should it be possible to install it anywhere ? Fixed path? I have not looked at the old SDK, but my plan is to have it like the build tree so you should be able to put it anywhere. Well, once you build and install the SDK, the PROJECTROOT gets expanded in the Imakefiles/Makefiles, and it has problem during the build phase if you moved it, since it tries to erase files in the old location, for which it may not have the rights. I was able to override this behavior by calling make wile overriding one of the make variables, i forgot which one right now, but i think it was something like USRINCDIR or something such. Ideally it would be easy to build in any place, possibly not as root, and then to be able to install as root, and with the install path accepting the $(DESTDIR) prefix, so the drivers can be installed into a package. Friendly, Sven Luther Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] [Q] : where to submit patches?
Ar an 2ú lá de mí 6, scríobh Egbert Eich : Aidan Kehoe writes: Ar an 2ú lá de mí 6, scríobh Egbert Eich : Also they seem to have difficulties to make attachments NB; this is not a badly-designed-user-interface issue; bugzilla on bugs.xfree86.org is _buggy_ with regard to creating patches. Maybe you have misunderstood me: I understood you; unfortunately what I was trying to say in my head didn't make it to the keyboard in one piece. I meant to say, bugzilla on bugs.xfree86.org is buggy with regard to creating attachments. If people put patches (that is, diff(1) output) into the comments field, it was frequently because creating attachments wasn't working for them. That said, perhaps this has been fixed lately; I haven't noticed as many people putting diff output into comments in the last few weeks. -- Parhásárd; rex quondam Pokémonorum, rex futuram Pokémonorum. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bugzilla
Hello Egbert, First people advocated that XFree86 has a bugzilla. Now we have one and people complain that it is broken. Our expertise is developing X not running a bugzilla. Where are the people with this expertise, the volunteers who step up and offer to help us to tweak it so it suits our needs best? I have some limited experience with bugzilla, having it adapted and introduced within our company. If someone could at least list some of the problems, so that I can estimate the time requirements, I would be willing to maintain the XFree86 bugzilla. About me: Using Linux for about 10 years; working professionally with Linux as a SW architect in embedded and server environments. btw. we know each other from some Linux meetings, I am the guy talking about the ct driver for embedded system requirements; maybe you remember. Regards, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] [Q] : where to submit patches?
Ar an 3ú lá de mí 6, scríobh Egbert Eich : Egbert Eich writes: Aidan Kehoe writes: Ar an 2ú lá de mí 6, scríobh Egbert Eich : Also they seem to have difficulties to make attachments NB; this is not a badly-designed-user-interface issue; bugzilla on bugs.xfree86.org is _buggy_ with regard to creating patches. [...] And I forgot to add: First people advocated that XFree86 has a bugzilla. Now we have one and people complain that it is broken. Bugzilla is great, it's a valuable tool, and thank you all for putting it in place. It certainly makes life easier for the rest of the world who don't have CVS access, and I suspect it makes life easier for you too. As someone who has put diff output into comment fields, though, I wanted to point out that people have had good reason for doing so. We weren't just trying to make your life more difficult, even if it sometimes seems that way. Our expertise is developing X not running a bugzilla. Where are the people with this expertise, the volunteers who step up and offer to help us to tweak it so it suits our needs best? Where is the community spirit? I definitely miss it here in this list. Okay, I'm a long way from being a Perl expert, but I can try; what version of Bugzilla is being used on that machine? Was it installed as a Debian package, or by hand? -- Parhásárd; rex quondam Pokémonorum, rex futuram Pokémonorum. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] [Q] : where to submit patches?
On Tue, 3 Jun 2003, Aidan Kehoe wrote: Okay, I'm a long way from being a Perl expert, but I can try; what version of Bugzilla is being used on that machine? Was it installed as a Debian package, or by hand? As the Debian package. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: OpenGL + XvMC
Can you use those non-power-of-two mpeg surfaces as normal textures without limitations? I don't think most hardware can do that, some possibly can't at all. Well for one thing my XvMC surfaces ARE power of two, but that is not the point. The HWMC engine used the very same texture engine as is used for 3d. So while the planar surfaces are not _great_ for use as textures it can be done. It is probably just as much bandwidth due to an internal conversion but the YUV planar to YUV packed conversion could happen render time into a temporary buffer. In the end, I think this is more of a neat trick than anything else so I don't think it matters a whole lot if there is an extra copy. I keep thinking that some sort of Direct Rendered Video extension would be very useful for X. You could then alloc a direct video surface that was mappable. Populate it from the final write in the decode process (From ANY codec) then either do a Put() a Blend() or a CopytoPBuffer(). The CopytoPBuffer() may be unnecessary if you could do a CreatePBufferFromXvD() to share the surface. In such a scenario I think the ability to save the copy is quite important. I am interested in getting mpeg into textures for the purpose of incorporating into 3D scenes and video editing/post production. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
iBook us-keyboard problem
I have an iBook with a US keyboard layout, and I'm having a wierd problem I hope you can help with. The mac keyboards have a keypad equals key. X doesn't support that as separate from regular equals, but I'd like to use it to type equals. The problem is that both this KP-equals and the left-arrow key have the same keysyms. If I try to modify one, I modify both. Here's the relevent xev output: KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558015, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: KeyRelease event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558135, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35560194, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: I am actually hitting different keys here, but it doesn't look like it. What is wierd is that these keys generate different keysyms and characters on the console. I type an '=' with both keys (on Debian sid). I had a suggestion to look in the XF86 keyboard code. Does anyone here have an idea of which files to start to look in? Will this be a C-code problem or a configuration issue somewhere? Or does anyone know how to see the scancodes that X thinks I have? Here's the version info from the top of the XFree86.0.log: XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-ben8-xfs-lolat ppc [ELF] I'm using the Xserver packages that Michael Däzner provides. Do you need any other info? Thanks for any help, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
Hi Michel, My attempts at using the binary have failed. X reports: (II) LoadModule: radeon (II) Loading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (II) Module radeon: vendor=The XFree86 Project compiled for 4.3.99.5, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 (EE) module ABI minor version (7) is newer than the server's version (6) (II) UnloadModule: radeon (II) Unloading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (EE) Failed to load module radeon (module requirement mismatch, 0) I've tried and failed to build a new dri-trunk package incorporating the patch (most likely a newbie deb package building/xfree86 compiling problem). My package versions are: xserver-xfree86 4.2.1-6 the XFree86 X server xserver-xfree86-dri-trunk 2003.05.04-1 The XFree86 X server [DRI trunk] If this is due to your binary being compiled against a different version of X than my own, what can I do? Should I try it with a 4.3 server? (and if so, are some official debs available?) Could you compile it against a lower version for me? Or shall I just give up on this whilst somebody else with more xfree86 smarts tests it? :( Thanks, John. On Wed, 2003-06-04 at 00:19, Michel Dänzer wrote: On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? -- GPG KEY: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 HTTP: http://www.johnleach.co.uk signature.asc Description: This is a digitally signed message part
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems with XFree86
On Wed, Jun 04, 2003 at 12:08:47PM +0100, John Leach wrote: Hi Michel, My attempts at using the binary have failed. X reports: (II) LoadModule: radeon (II) Loading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (II) Module radeon: vendor=The XFree86 Project compiled for 4.3.99.5, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 (EE) module ABI minor version (7) is newer than the server's version (6) (II) UnloadModule: radeon (II) Unloading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (EE) Failed to load module radeon (module requirement mismatch, 0) I've tried and failed to build a new dri-trunk package incorporating the patch (most likely a newbie deb package building/xfree86 compiling problem). My package versions are: xserver-xfree86 4.2.1-6 the XFree86 X server xserver-xfree86-dri-trunk 2003.05.04-1 The XFree86 X server [DRI trunk] If this is due to your binary being compiled against a different version of X than my own, what can I do? Should I try it with a 4.3 server? (and if so, are some official debs available?) Could you compile it against a lower version for me? Or shall I just give up on this whilst somebody else with more xfree86 smarts tests it? :( 4.3.0 debs are available at: deb http://penguinppc.org/~daniels/sid/$(ARCH) ./ -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgp0.pgp Description: PGP signature
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems with XFree86
On Wednesday, June 4, 2003, at 01:19 AM, Michel Dänzer wrote: On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? I tried the patch, but without any visible results :(. I was digging a bit more in the wrong colors issue and found out the following: When I'm running the CRT,CRT layout (as opposed to the previous CRT,TMDS) the colors behave differently. In fact is seems like a common endianess-problem: the layout of colors is 0xBBGGRR00 in Mac big-endian notation, but the color on the screen written by the driver are 0x00RRGGBB - that is the colors red and green are swapped and blue is never seen. This is true for both screens. So the summary (CVS XFree): * CRT,CRT mode: swapped 'byte-sex' causes wrong colors, otherwise both screens are OK * CRT,TMDS mode: CRT screen is off, TMDS has split colors - i.e. the low and high 4 bits of the components are interlaced I wanted to look at the code, but I can't seem to find any tech info on the Radeon chip - is it available to the chosen only after signing a NDA? Any help, especially with the CRT+TMDS mode is highly appreciated! Cheers, Simon PS: Additional info for Ben: In fact the kernel radeon driver works with the DFP *only* - in CRT,CRT layout the kernel hangs in the early-boot screen (and doesn't go further - no network etc.). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
