RE: C+T 69030 driver on powerpc
Am now making some progress on the mangled graphics: When i have acceleration turned on, glyph drawing is a complete mess. it looks like the bits are being expanded backwards and characters are being read from the wrong place. I've gone through CPUToScreenColorExpandFill with a fine tooth comb, but can't see anything wrong, and all my MMIO_OUT32 writes into BRxx are correctly expanding into xf86WriteMmio32Le. Have you ever seen anything like this before? Thanks, Rob Taylor whoo! fixed! ok attached are my initial diffs, i'm gonna do soem work to clean this up, cos there are a number of ordering issues in the driver, so a bit of reorganization is probably in order (pun not intended...) ok 1st issue - cPtr-Bus was only getting set a long time after the 1st chipsMapMem, so changed logic here, also need to change this in a couple of other places also. 2nd issue - not sure if I'm right here, but it seems wrong to be using VIDMEM_MMIO_32BIT for vga register mapping.. taken a leaf from nv driver and mapped it as VIDMEM_MMIO | VIDMEM_READSIDEEFFECT. 3rd issue - VGAHWPTR(pScrn)-IOBase was being set before we'd registered the custom vga access functions, so was being read incorrectly. hence, even when my mapping was right, it was trying to read from the MDA ST01, rather than the CGA ST01. :D An issues I'm getting now, which I assume is endian-related is that my HWCursor is mangled (bytes the wrong way around) where do I tell the xserver how to draw into my words correctly? Thanks, Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Nvidia driver relation to XFree
one way to do what you want (from kernel space) is to use the kernel framebuffer driver for writing graphics, and use up one of the VT's for your debugger, switching to that vt when doing, umm, whatever your doing I have to ask tho, whats wrong with kgdb? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Roberts Sent: 03 November 2003 18:09 To: [EMAIL PROTECTED] Subject: Re: Nvidia driver relation to XFree On Mon, 03 Nov 2003 17:51:53 +0100, Gerhard W. Gruber wrote: I'm working on a kernel debugger which is similar to SoftICE on WIndows. I would like to take advantage of the graphics mode when a user activates the debugger under X and so I was investigating how to solve this. When I use normal VGA mode it doesn't work on my card when I have X running while a fellow coder has a similar card with also nvidia drvier and it works for him (more or less). Now I wonder what is the relation of the video driver to X. The video driver is part of XFree86. What is happening when i.e. the user changes to a console? X must save the current state of the VGA card (i.e. resolution, frequency, etc.) and switch to a suitable console mode. Basically, yes. It isn't usually necessary to save the graphics state; the driver put the card in a graphics state initially, and since it still knows the parameters requested in the XF86Config file, it can put the card back into that state whenever it wishes. However, the driver does have to save the INITIAL state of the graphics card when the driver starts up so it can restore that before switching back to a console. The console driver does NOT know how to switch back to text mode, so XFree86 must insure that the card is in its original condition before allowing the VT switch to go on. Similarily when the user switches back to X this has to be reversed and the state restored. Now I wonder how exactly this is going to happen. Since nvidia doesn't open it's code I can't look at it, but there has to be some interface so that X can do this stuff without knowing the details of the driver. The driver is part of XFree86. Each driver has functions called EnterVT and LeaveVT (where depends on the driver name) that implement the switch to and from a console (VT = virtual terminal). Go look through some of the drivers and you can see how it is done. Can I use this interface in kernel modules as well? I think it should be possible. Absolutely not. XFree86 drivers are just user-mode shared object files loaded by the XFree86 executable. They use a custom API and call a bunch of user-mode functions. They will not work in kernel mode. Another thing is, that I would like to take advantage of the current display and draw my window directly into the framebuffer. Is this possible? Haven't we had this conversation before? I know that I can install the framebuffer support for the kernel and then I would have an interface to do this, but I wonder how X is doing that. The XFree86 driver has INTIMATE knowledge of the specific graphics card. Typically, the driver goes out and reads the PCI configuration registers (or allows XFree86 to do it) to get the physical addresses assigned to the board. Because the driver knows the card, it knows which of the addresses is the frame buffer and which has the memory-mapped registers. It maps that space into user-mode address space, and starts writing. Can I get the pointer to the framebuffer and use it, or is there some way to do this via an interface through the driver. It is not exaclty clear to me on how X and nvidia.o are related to each other. nvidia.o is part of XFree86. It is a dynamically-loaded library that implements the same interface as all other XFree86 video drivers, and it calls back in to the XFree86 executable and its other drivers for most of its services. Of course the same holds true for other cards, so the best solution for my purpose would be to find some way that is more or less independent of the card, but I guess this is to much to ask for. :) DGA is one was for you to take ownership of the frame buffer, but like all of XFree86, it is a user-mode service. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
so I correct myself. looks like its nothing to do with the kernel framebuffer driver. it mroe to do with the state the card gets left in after being half configured *phew*!! so thats makes life a bit easier - i just need to fix the card configuration! This should not happen. It can only happen when the Xserver has the ROM BIOS mapped. Judging from your log that shouldn't happen. Can you find out where it happens? You can hardcode a test for the relevant PCI config space register and PCI tag in the appropriate PciWrite() function and call a function you can breakpoint from gdb. There are three functions for this purpose: xf86Break1/2/3(). Debugged! The mangling occurs when it trys and fails to map the ROM BIOS (and of course my embedded board doesnt have a rom bios..). Mangling occurs in handlePciBIOS, i'm afraid i'm not knowledgable enough about how this code should work to explain why, tho. It seems that when xf86ReadDomainMemory fails and it tries to restore the base register with if (savebase) pciWriteLong(Tag, PCI_MAP_REG_START + (b_reg 2),(CARD32) savebase); (where b_reg=0, savebase=0xfa00) the card doesnt like this and resets BASE0! (i.e. the line 'BASE0 0xfa00 addr 0xfa00 MEM' disappears from scanpci -v) odd. Luckily i can just work around this using NoINT10 :) Onwards! Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Egbert Eich writes: Rob Taylor writes: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? well I now know why i get 0xff00 for the set up device - its MBASE0 is 0x000 when we do xf86scanpci, and PCINONSYSTEMCLASSES(baseclass, subclass) is true hence pciCheckForBrokenBase gets called, which will set MBASE0 to 0x, and as only the top byte is writable (16Meg chunks) MBASE0 becomes 0xff00. not that this seems to help me much. i'm just more confused now!! why on earth would mbase0 be 0, if its in use and /proc says the device's memory is at 0xfa0???! really just posting this here incase anyone else ever wants to know... =) Can you add some code to xf86scanpci() to find out why it's 0? On PPC PCI config space data gets obtained thru the kernel, therefore it is even harder to understand. Also could you please run 'scanpci -v'? In case you missed my previous mail, it appears that mbase0==0 is something to do with the as69030 kernel framebuffer driver i'm running. If i compile a kernel without fbdev, pci probing works fine. I've stepped though the failure case in xf86scanpci(). It's 0 because when we read the config space from the device into devp-cfgspc.dwords, we read 0 for the word corresponding to MBASE0, so defintly seems like some kind of hardware config level issue. Note that I have 2x69030's on this board, so perhaps intersting stuff happens because of that. i note that only the 1st device gets read as 0x, the second device gets correctly read as 0xfb00! One solution I'm considering is to use the framebuffer interface to mmap the device if the framebuffer driver is availiable, and using the current scheme if not. Unfortunatly I still get issues even with an non fbdev kernel. I think this is due to the fact that the big-endian hack (+0x80) only really works on a couple of HiQV chips. On the as69030, it uses 1st 8 Meg for Pipe A and 2nd 8 meg for Pipe B. There *is* a single pipe mode where it will put a byte swapped frame buffer at +0x80, but thats all (no registers), and obviously that isn't much use. So, I guess I'll be going though the driver and checking all its byte-swapping macros are properly in place, stripping out the +0x80 hack, and just telling X the correct pixel bit ordering! Make sense? Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Tim Roberts writes: On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. Right, that's exactly the reason for this. The BE support was tested for one of the HiQV chipsets - however I'm not sure if it was tested for the 69030. thanks for the info! google now tells me that Michael Stephen Hanni wrote the +0x8 hack for running ct65550 on his powerbook 3400 :) Currently theres a a lot of possibiliites as to what could be going wrong, so knowing whats right's a good place to start :) I'll try and get a well formed patch in when i get this all working (and I *will* get it working... *grr* ;)) noticed i forgot to mention the immediate symtoms in my last post - the driver starts up, the server gets to running, but there's no display, no change in output whatsover... We're running an fbdev driver for the card in the kernel, could i be seeing some sort of resorce allocation problem? We currently run an fbdev based driver in Xfree86 that works flawlessly but leaves a lot to be desired on the accelaration side, so hardware is all good. Thanks Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
C+T 69030 driver on powerpc
Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Thanks to anyone who can spread some light on this for me! Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: User sponsored drivers
Surely it'd be less difficult nowadays, with the job market in its current state? Rob On Tue, 15 Jul 2003, Alex Deucher wrote: This proposal comes up periodically on this and other xfree lists, but never really goes anywhere. Why not raise money from the open source community to fund open source driver development? It is very difficult to convert money into code. It's probably easier to raise the money than it is to find a way to convert that into code. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Xrandr developer
Jim Gettys and Keith Packard are teh main protagonists, however Jim has been busy recuperating from a broken ankle, and Keith has been involved in some political stuff - see the 'forum' mailing for details. It seems the best thing to do at the moment is for those of us interested in XRandR development to get together, plan out some work, log bugs/features in bugzilla and then do some coding. I'm interested in making it work with xinerama, whats your interest? Rob Taylor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Woerle Paceblade/Support Sent: 27 March 2003 08:43 To: [EMAIL PROTECTED] Subject: Xrandr developer Hi who is maintaining the XRANR extension ??? i need contact since i want to enhance it Cheers Rob -- _ *Robert Woerle **Technical Support | Linux PaceBlade Technology Europe SA* phone:+49 89 552 99935 fax: +49 89 552 99910 mobile: +49 179 474 45 27 email:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] web: http://www.paceblade.com _ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: FW: [Xpert]2 mice - 2 pointer ?!?
We have a product that can have up to 4 touch screens and has a track-ball controlled pointer. Iften people operate the product in a two-handed manner, and occasionally more than one operator will use the product at a given time. the upshot of this is that ideally there would be a pointer for the trackball that isn't effected by touchscreen presses, and separate invisible pointers for each of the touchscreens. The setup is currently impossible in Xfree86. I'm beginning to understand what you want here. I don't think you really need pointers for the touch-screens; just events when they are pressed. I haven't checked, but I think that one of the standard extensions (perhaps XInputExtension) should be able to do that for you. At some level this isn't really a mouse click; if you want standard apps to behave as if they received a mouse-click, then you want a wrapper app to convert touch-screen presses into synthetic events sent to the standard app (perhaps indirectly via the window manager). Thats a pretty good idea, i'll have a delve into that for my current application. I'd say, however that this functionality is something almost all multiple touchscreen users will want, so that doesnt help everyone. Another concrete example is when implementing a collaborative decktop in whcih you want a separate pointer for each of the users remotely viewing that desktop. Are you going to let them type into different windows at the same time ? That really would be two pointers. However I think that should be done by the collaboration software, not by X. How could the collaborations software do this if X cant support multiple main focuses? I presume you would have an app that is in charge of reading the 'remote events' and draws two virtual mouse pointers and sythetically delivers the events? I'm not convinced that two pointers are a good idea on a collaborative desktop, forcing the participants to share a pointer helps them to share their focus. Without it they could easily each do their own thing and stop watching what the other one is doing: a good way to reduce the efficiency of the collaboration ? Its something people want to do... *shug* not my area, but i've seen several discussions about it. And don't forget that most current graphics cards only have one hardware cursor. XFree86 still has framework for soft cursors, no? Anyhow, thanks for the solution! Its a shame that X isn't going to be able to cope with multiple focus trees, but I agree the issues are many, and the need little... Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
