Menu
▾
▴
linux-apus-devel
|
From: <gri...@ps...> - 2000-09-22 12:16:38
|
We're gonna need drivers... http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 Voodoo3 anyone? Bye, Arno. -- PSINetworks Europe Fax: +31-23-5699841 | One disk to rule them all, Siriusdreef 34 Tel: +31-23-5699840 | One disk to bind them, 2132WT Hoofddorp+--------------------------------+ One disk to hold the files The Netherlands | * Musical Interlude * | And in the darkness grind 'em ----------------+--------------------------------+------------------------------ We say Retribution, We say Vengeance is bliss, We say Revolution, With a Cast-Iron fist! (Megadeth, 'The Disintegrators') -------------------------------------------------------------------------------- |
|
From: <p2...@mi...> - 2000-09-22 12:38:38
|
On Fri, Sep 22, 2000 at 02:16:34PM +0200, Arno Griffioen wrote: > We're gonna need drivers... > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 > > Voodoo3 anyone? > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. Text console is accelerated. Peter. |
|
From: <ko...@nv...> - 2000-09-22 12:57:38
|
On Fri, 22 Sep 2000, p2 wrote: > > Voodoo3 anyone? > > > > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. > Text console is accelerated. Using the Mediator? -- kolla |
|
From: <p2...@mi...> - 2000-09-22 14:22:27
|
On Fri, Sep 22, 2000 at 02:49:58PM +0200, Kolbjørn Barmen wrote: > On Fri, 22 Sep 2000, p2 wrote: > > > > Voodoo3 anyone? > > > > > > > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. > > Text console is accelerated. > > Using the Mediator? > No, on a CHRP board with GoldenGate II chipset and 604e CPU. But most big endian issues with the code are solved. PCI I/O space access is required however... Peter. |
|
From: Christian T. S. <ct...@de...> - 2000-09-22 12:47:17
|
On Fri, Sep 22, 2000 at 02:16:34PM +0200, Arno Griffioen wrote: > We're gonna need drivers... > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 Its still vapourware: http://www.amiga-news.de/index.shtml (sorry, german) Official Annoucement from Elbox [...] Aufgrund der Tatsache, dass keine dieser PCI-Lösungen bisher auf dem Markt erhältlich sind, ist es derzeit nicht möglich, dem Wahrheitsgehalt beider Varianten auf den Zahn zu fühlen. I propose somebody write some patches to make xfree4.0 compile instead. That would help many more people, than writing drivers for not yet existing hardware for not yet quite dead computers. Wasn't there some xfree developer around? It seems to me the very basic m68k support is missing in xfree 4.0.1, at least what I get in the debian package. And I am pretty sure m68k support has not been removed by the debian maintainer... Christian -- http://www.debian.org/~cts/debian-m68k/potato |
|
From: Alan B. <al...@ms...> - 2000-09-22 13:32:34
|
hi, > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 > Its still vapourware: http://www.amiga-news.de/index.shtml (sorry, german) > Official Annoucement from Elbox whats still vapour-ware? the Elbox Mediator PCI BUSBoard for the A1200 certainly isnt, I saw one in action 2 weeks ago. It was using a VirgeS3 PCI gfx card (basic driver changes for AmigaOS cybergfx to use) and was running very happily at 1280x1024 in 16bit. > I propose somebody write some patches to make xfree4.0 compile instead. That > would help many more people, than writing drivers for not yet existing > hardware for not yet quite dead computers. Wasn't there some xfree developer > around? It seems to me the very basic m68k support is missing in xfree > 4.0.1, at least what I get in the debian package. And I am pretty sure m68k > support has not been removed by the debian maintainer... i dont see the issue. this uses standard PCI calls - so, once you know where the PCI memory lies you should be able to use the current XFree4 drivers - for 3dfx, ATI, Virge etc etc, yes? - of course, if m68k doesnt have XFree4 yet, then that *is* an issue alan |
|
From: Michel <dae...@st...> - 2000-09-22 13:40:34
|
Alan Buxey wrote: > > I propose somebody write some patches to make xfree4.0 compile instead. > > That would help many more people, than writing drivers for not yet > > existing hardware for not yet quite dead computers. Wasn't there some > > xfree developer around? It seems to me the very basic m68k support is > > missing in xfree 4.0.1, at least what I get in the debian package. And I > > am pretty sure m68k support has not been removed by the debian > > maintainer... > > i dont see the issue. this uses standard PCI calls - so, once you know > where the PCI memory lies you should be able to use the current XFree4 > drivers - for 3dfx, ATI, Virge etc etc, yes? The problem is that AFAIK the Mediator only gives access to the memory space via the ZIII window. The X 4 drivers (like all Linux PCI drivers I guess) assume a contiguous memory space. I guess this could be solved with MMU tricks, but is it worth the trouble? The Predator board will offer contiguous memory for PPC boards. > - of course, if m68k doesnt have XFree4 yet, then that *is* an issue Does m68k even have PCI yet? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: Alan B. <al...@ms...> - 2000-09-22 14:12:04
|
hi, > The problem is that AFAIK the Mediator only gives access to the memory space > via the ZIII window. The X 4 drivers (like all Linux PCI drivers I guess) > assume a contiguous memory space. I guess this could be solved with MMU > tricks, but is it worth the trouble? The Predator board will offer contiguous > memory for PPC boards. thats if it comes, most people i know think that the predator is vapour - I'm still to be convinced as to how a BUSBoard can hang off the delicate PPC connector ;-) > > - of course, if m68k doesnt have XFree4 yet, then that *is* an issue > > Does m68k even have PCI yet? 8-) surely some 68k machines have had PCI already, n'est pas? alan |
|
From: Creasey <sa...@oh...> - 2000-09-22 14:00:28
|
On Fri, 22 Sep 2000, Alan Buxey wrote: > drivers - for 3dfx, ATI, Virge etc etc, yes? - of course, if m68k doesnt > have XFree4 yet, then that *is* an issue I'm almost ashamed to admit this, but XF4 does build on a sun3(linux). :) didn't get to actually test the X server (though it built). no kbd/monitor... everything else worked like a champ. So it should be plenty possible :) -- Sam "UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS." -- Robert E. McElwaine |
|
From: Michael S. <sc...@op...> - 2000-09-22 18:37:52
|
> I propose somebody write some patches to make xfree4.0 compile instead. That > would help many more people, than writing drivers for not yet existing > hardware for not yet quite dead computers. Wasn't there some xfree developer > around? It seems to me the very basic m68k support is missing in xfree The previous m68k xfree developer (Geert, in case you forgot) asked for takers quite a while ago. So AFAIK there's no m68k developer for xfree right now. I know just barely enough to screw up a xfree build, and I don't have a fast m68k for builds. Just in case you were about to ask. Michael |
|
From: Christian T. S. <ct...@de...> - 2000-09-23 20:55:42
|
On Fri, Sep 22, 2000 at 08:37:33PM +0200, Michael Schmitz wrote: > I know just barely enough to screw up a xfree build, and I don't have a > fast m68k for builds. Just in case you were about to ask. Well, ask me, I know barely enough to circumvent the glitches in the debian package to make 3.3.6 build. Ok, here comes the problem. I made patches for two Imakefile errors, build fails now here: gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy -Wl,-rpath-link,../../../../../exports/lib pcitweak.o: In function `main': pcitweak.o(.text+0x138): undefined reference to `xf86scanpci' pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci' pcitweak.o(.text+0x2b8): undefined reference to `pciTag' pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte' pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord' pcitweak.o(.text+0x306): undefined reference to `pciReadLong' pcitweak.o(.text+0x338): undefined reference to `pciWriteByte' pcitweak.o(.text+0x350): undefined reference to `pciWriteWord' pcitweak.o(.text+0x360): undefined reference to `pciWriteLong' collect2: ld returned 1 exit status make[7]: *** [pcitweak] Error 1 make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc' In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus some *Pci.c files for several arches exist, but none for m68k. The files say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only have /proc/bus/zorro, but not pci... so maybe it would not make sense to add m68k to the Imakefile? However, without pci, I have some problems to get xfree4.0 to build, see error messages above. I think (anybody with a clue correct me please) that XF4.0 requires some pci functions, or some major rework in the (I)Makefiles and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci functions for m68k) or maybe even a patch, I'd be happy to hear about it. Christian |
|
From: Michael S. <sc...@zi...> - 2000-09-23 22:10:40
|
> > I know just barely enough to screw up a xfree build, and I don't have a > > fast m68k for builds. Just in case you were about to ask. > Well, ask me, I know barely enough to circumvent the glitches in the debian > package to make 3.3.6 build. I haven't even done that for a long time. > Ok, here comes the problem. I made patches for two Imakefile errors, build > fails now here: > > gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy -Wl,-rpath-link,../../../../../exports/lib > pcitweak.o: In function `main': > pcitweak.o(.text+0x138): undefined reference to `xf86scanpci' > pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci' > pcitweak.o(.text+0x2b8): undefined reference to `pciTag' > pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte' > pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord' > pcitweak.o(.text+0x306): undefined reference to `pciReadLong' > pcitweak.o(.text+0x338): undefined reference to `pciWriteByte' > pcitweak.o(.text+0x350): undefined reference to `pciWriteWord' > pcitweak.o(.text+0x360): undefined reference to `pciWriteLong' > collect2: ld returned 1 exit status > make[7]: *** [pcitweak] Error 1 > make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc' > > In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus > some *Pci.c files for several arches exist, but none for m68k. The files > say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only > have /proc/bus/zorro, but not pci... so maybe it would not make sense to add > m68k to the Imakefile? No, that would not make sense unless we add code in the kernel to masquerade the m68k builtin framebuffer devices as PCI devices of some sort (and I don't just mean support for /proc/bus/pci). Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or EISA but no PCI bus? Does this still work, at all?? > However, without pci, I have some problems to get xfree4.0 to build, see > error messages above. I think (anybody with a clue correct me please) that > XF4.0 requires some pci functions, or some major rework in the (I)Makefiles > and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci > functions for m68k) or maybe even a patch, I'd be happy to hear about it. There should be a way (in site.def, perhaps) to say 'there's no PCI on this architecture, use other access methods like VGA or fbdev'. If that's not possible, dummy PCI functions could be implemented that just return -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does what it is supposed to in this case: fall back on fbdev to map and access the hardware. If even that isn't possible, the design of XFree86 4.0 is badly broken (not that I'd be surprised; in my eyes the way XFree messes with PCI resources bypassing the kernel is a big design flaw and just asking for trouble). Just my idea. I'm sure the xperts disagree. We don't have a XFree maintainer to take care of this anyway, it's not your job as the person stuck with the task of building X for Debian/68k, and I doubt you'll get Branden to do the heavy lifting on behalf of m68k. Unless someone is found to take care of the fundamental XFree problems on m68k, there won't be XFree86 4.x for m68k. Michael |
|
From: Michel <dae...@st...> - 2000-09-23 22:22:23
|
Michael Schmitz wrote: > > In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus > > some *Pci.c files for several arches exist, but none for m68k. The files > > say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I > > only have /proc/bus/zorro, but not pci... so maybe it would not make sense > > to add m68k to the Imakefile? > > No, that would not make sense unless we add code in the kernel to > masquerade the m68k builtin framebuffer devices as PCI devices of some > sort (and I don't just mean support for /proc/bus/pci). I have implemented something like this for the Permedia2 based boards in the APUS tree. But I don't think it's feasible for all graphics hardware. > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or > EISA but no PCI bus? Does this still work, at all?? Yes. There's similar code for (E)ISA. > > However, without pci, I have some problems to get xfree4.0 to build, see > > error messages above. I think (anybody with a clue correct me please) that > > XF4.0 requires some pci functions, or some major rework in the > > (I)Makefiles and whatnot. So if somebody has a proposal (dummy, or maybe > > some "real" pci functions for m68k) or maybe even a patch, I'd be happy to > > hear about it. > > There should be a way (in site.def, perhaps) to say 'there's no PCI on > this architecture, use other access methods like VGA or fbdev'. If that's > not possible, dummy PCI functions could be implemented that just return > -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does > what it is supposed to in this case: fall back on fbdev to map and access > the hardware. Just look at the PPC PCI code, that works fine without /proc/pci - tested on APUS. > If even that isn't possible, the design of XFree86 4.0 is badly broken (not > that I'd be surprised; in my eyes the way XFree messes with PCI resources > bypassing the kernel is a big design flaw and just asking for trouble). Many people have complained about that, but they forget that XFree86 runs on a lot more OSs than just Linux which may not have such a convenient API for PCI. And even the older Linux kernels don't. Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: Michael S. <sc...@zi...> - 2000-09-23 22:45:07
|
> > No, that would not make sense unless we add code in the kernel to > > masquerade the m68k builtin framebuffer devices as PCI devices of some > > sort (and I don't just mean support for /proc/bus/pci). > > I have implemented something like this for the Permedia2 based boards in the > APUS tree. But I don't think it's feasible for all graphics hardware. I guess you have to create a fairly close emulation of real PCI hardware to fool XFree. I'd rather have XFree not assume PCI is available on Linux. > > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA or > > EISA but no PCI bus? Does this still work, at all?? > > Yes. There's similar code for (E)ISA. Good. That's just using hardcoded (S)VGA addresses? > > There should be a way (in site.def, perhaps) to say 'there's no PCI on > > this architecture, use other access methods like VGA or fbdev'. If that's > > not possible, dummy PCI functions could be implemented that just return > > -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree does > > what it is supposed to in this case: fall back on fbdev to map and access > > the hardware. > > Just look at the PPC PCI code, that works fine without /proc/pci - tested on > APUS. Does it also work without PCI hardware? > > If even that isn't possible, the design of XFree86 4.0 is badly broken (not > > that I'd be surprised; in my eyes the way XFree messes with PCI resources > > bypassing the kernel is a big design flaw and just asking for trouble). > > Many people have complained about that, but they forget that XFree86 runs on a > lot more OSs than just Linux which may not have such a convenient API for PCI. > And even the older Linux kernels don't. It's not about the convenient API for PCI but about the convenient API for mapping IO and memory of the graphics hardware plus the fbdev ioctls to set video modes, color entries and more. fbdev has been in the official kernel for quite a while now. I do know that the option UseFBDev will make XFree use the kernel fbdev API _once the card has been detected_. What I complain about is the lack of a mechanism to tell XFree 'don't touch this card, the kernel fbdev driver at /dev/fb<index> knows how to handle it' already at the probe stage. Right now there's no way for the kernel fbdev driver to figure out Xfree just disabled the PCI IO or memory resource for its card, resulting in the first kernel panics I've ever seen with XFree on sane (non-Intel) hardware. Makes me think about whether the GGI people had it right all the time. OTOH, it's all Apple's fault for setting up crazy PCI resources, and the kernel's fault for not demangling the PCI resource allocation. At least that's going to be solved in 2.4. Michael |
|
From: Michel <dae...@st...> - 2000-09-23 23:58:45
|
Michael Schmitz wrote: > > > > No, that would not make sense unless we add code in the kernel to > > > masquerade the m68k builtin framebuffer devices as PCI devices of some > > > sort (and I don't just mean support for /proc/bus/pci). > > > > I have implemented something like this for the Permedia2 based boards in > > the APUS tree. But I don't think it's feasible for all graphics hardware. > > I guess you have to create a fairly close emulation of real PCI hardware > to fool XFree. Right, not hard with the Permedia2 boards where the PCI config space is available. > I'd rather have XFree not assume PCI is available on Linux. It doesn't. Or at least it works without. > > > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA > > > or EISA but no PCI bus? Does this still work, at all?? > > > > Yes. There's similar code for (E)ISA. > > Good. That's just using hardcoded (S)VGA addresses? Dunno, haven't looked at the code. > > > There should be a way (in site.def, perhaps) to say 'there's no PCI on > > > this architecture, use other access methods like VGA or fbdev'. If > > > that's not possible, dummy PCI functions could be implemented that just > > > return -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree > > > does what it is supposed to in this case: fall back on fbdev to map and > > > access the hardware. > > > > Just look at the PPC PCI code, that works fine without /proc/pci - tested > > on APUS. > > Does it also work without PCI hardware? Yes, I had to add fbdev probing code to the glint driver though which is still considered a hack. > > > If even that isn't possible, the design of XFree86 4.0 is badly broken > > > (not that I'd be surprised; in my eyes the way XFree messes with PCI > > > resources bypassing the kernel is a big design flaw and just asking for > > > trouble). > > > > Many people have complained about that, but they forget that XFree86 runs > > on a lot more OSs than just Linux which may not have such a convenient API > > for PCI. And even the older Linux kernels don't. > > It's not about the convenient API for PCI but about the convenient API for > mapping IO and memory of the graphics hardware plus the fbdev ioctls to > set video modes, color entries and more. fbdev has been in the official > kernel for quite a while now. Yes, in the official _Linux_ kernel. What about all the BSDs, Solaris (I know that also has some kind of framebuffer device, but nobody has bothered to add code for that), the various System V flavours, OS/2, ... ? > I do know that the option UseFBDev will make XFree use the kernel fbdev > API _once the card has been detected_. What I complain about is the lack > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev > driver at /dev/fb<index> knows how to handle it' already at the probe stage. If you provide the bus ID, the X server won't mess with the device if the memory regions etc. are sane. Development is taking place to automate the (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily, patches go to pa...@XF... or fi...@XF..., design suggestions to xp...@XF... :) > Right now there's no way for the kernel fbdev driver to figure out > Xfree just disabled the PCI IO or memory resource for its card, resulting > in the first kernel panics I've ever seen with XFree on sane (non-Intel) > hardware. Makes me think about whether the GGI people had it right all the > time. > > OTOH, it's all Apple's fault for setting up crazy PCI resources, and the > kernel's fault for not demangling the PCI resource allocation. At least > that's going to be solved in 2.4. Exactly, setting up sane PCI regions is a kernel task IMHO and I consider it plausible for the X server to assume that overlapping regions are a problem. Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: Michael S. <sc...@zi...> - 2000-09-25 07:36:02
|
> > > Just look at the PPC PCI code, that works fine without /proc/pci - tested > > > on APUS. > > > > Does it also work without PCI hardware? > > Yes, I had to add fbdev probing code to the glint driver though which is still > considered a hack. Fine, that could be a starting point. > > It's not about the convenient API for PCI but about the convenient API for > > mapping IO and memory of the graphics hardware plus the fbdev ioctls to > > set video modes, color entries and more. fbdev has been in the official > > kernel for quite a while now. > > Yes, in the official _Linux_ kernel. What about all the BSDs, Solaris (I know > that also has some kind of framebuffer device, but nobody has bothered to add > code for that), the various System V flavours, OS/2, ... ? I was talking about Linux here. Obviously, on systems without a sane method to access the display, the low level hacks^H^H^H^Hooks have to be used. > > I do know that the option UseFBDev will make XFree use the kernel fbdev > > API _once the card has been detected_. What I complain about is the lack > > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev > > driver at /dev/fb<index> knows how to handle it' already at the probe stage. > > If you provide the bus ID, the X server won't mess with the device if the > memory regions etc. are sane. Development is taking place to automate the Nothing in Apple space has ever been 'sane'. And in the case of the Rage Pro, the card design isn't sane to begin with (regardless where you map the MMIO regions in PCI config space, they always show up at the end of both little and big endian video RAM apertures). The kernel (Linux, that is :-) fbdev driver just uses the > (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily, > patches go to pa...@XF... or fi...@XF..., design suggestions to > xp...@XF... :) Add a fbdev->private field to hold PCI/Zorro/ISA/whatever dependent framebuffer information, and an ioctl to retrieve that bit. That's only my .01 Euro, and Geert may have reasons not to implement this. WRT X: I have a hard time to grok the convoluted structure of the X code. Easier to work around such X quirks, f.e. in the kernel (I tried to somehow keep X from messing with my PCI config to no avail). Don't look for any X patches of mine. Michael |
|
From: Michel <dae...@st...> - 2000-09-25 17:53:13
|
Michael Schmitz wrote: > WRT X: I have a hard time to grok the convoluted structure of the X code. > Easier to work around such X quirks, f.e. in the kernel (I tried to > somehow keep X from messing with my PCI config to no avail). Granted, the XFree86 tree is complex and takes time to learn one's way around. I don't see a significant difference to the Linux kernel tree though. > Don't look for any X patches of mine. I ask you to be constructive. If you can't improve it yourself, it would be nice if you at least contacted the responsible people with your ideas how to do it better. Instead of complaining everywhere. Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: Michael S. <sc...@op...> - 2000-09-25 20:29:31
|
> > WRT X: I have a hard time to grok the convoluted structure of the X code. > > Easier to work around such X quirks, f.e. in the kernel (I tried to > > somehow keep X from messing with my PCI config to no avail). > > Granted, the XFree86 tree is complex and takes time to learn one's way around. > I don't see a significant difference to the Linux kernel tree though. The significant difference being I have more or less learned my way around part of the latter. Plus the Linux kernel doesn't use a friggin' new data type for every other function or variable that I need to look up separately :-) > > Don't look for any X patches of mine. > > I ask you to be constructive. If you can't improve it yourself, it would be > nice if you at least contacted the responsible people with your ideas how to > do it better. Instead of complaining everywhere. I could do that - once I've talked to Geert about what would be required on the kernel side to support a new fbdev ioctl. I'd be surprised to hear anything besides 'it's the kernels fault' or 'send a patch' though. Michael |
|
From: Geert U. <ge...@li...> - 2000-09-26 17:49:15
|
On Mon, 25 Sep 2000, Michael Schmitz wrote:
> > (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,
> > patches go to pa...@XF... or fi...@XF..., design suggestions to
> > xp...@XF... :)
>
> Add a fbdev->private field to hold PCI/Zorro/ISA/whatever dependent
> framebuffer information, and an ioctl to retrieve that bit. That's only my
> .01 Euro, and Geert may have reasons not to implement this.
I'd say: why add the ioctl if you can do without it? It's not difficult to
match fbdevs and PCI devs, just look at the addresses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2000-09-26 10:07:18
|
On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> Michael Schmitz wrote:
> > I do know that the option UseFBDev will make XFree use the kernel fbdev
> > API _once the card has been detected_. What I complain about is the lack
> > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> > driver at /dev/fb<index> knows how to handle it' already at the probe stage.
>
> If you provide the bus ID, the X server won't mess with the device if the
> memory regions etc. are sane. Development is taking place to automate the
> (non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,
> patches go to pa...@XF... or fi...@XF..., design suggestions to
> xp...@XF... :)
However, it's quite easy to match fbdevs with PCI devs, cfr. the patches I
send to Michel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Michel <da...@re...> - 2000-09-26 11:27:39
|
Geert Uytterhoeven wrote: > > On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote: > > Michael Schmitz wrote: > > > I do know that the option UseFBDev will make XFree use the kernel fbdev > > > API _once the card has been detected_. What I complain about is the lack > > > of a mechanism to tell XFree 'don't touch this card, the kernel fbdev > > > driver at /dev/fb<index> knows how to handle it' already at the probe > > stage. > > > > If you provide the bus ID, the X server won't mess with the device if the > > memory regions etc. are sane. Development is taking place to automate the > > (non-trivial) assignment fbdev <-> pcidev . If you know how to do it > > easily, > > > patches go to pa...@XF... or fi...@XF..., design suggestions > > to xp...@XF... :) > > However, it's quite easy to match fbdevs with PCI devs, cfr. the patches I > send to Michel. Unfortunately, your patch doesn't work with the r128 driver, only with the plain fbdev driver. I'll have to investigate what's going on, but even more so why the MMIO region isn't mapped correctly... Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |
|
From: Geert U. <ge...@li...> - 2000-09-25 12:47:14
|
On Sun, 24 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> Michael Schmitz wrote:
> > > In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> > > some *Pci.c files for several arches exist, but none for m68k. The files
> > > say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I
> > > only have /proc/bus/zorro, but not pci... so maybe it would not make sense
> > > to add m68k to the Imakefile?
> >
> > No, that would not make sense unless we add code in the kernel to
> > masquerade the m68k builtin framebuffer devices as PCI devices of some
> > sort (and I don't just mean support for /proc/bus/pci).
>
> I have implemented something like this for the Permedia2 based boards in the
> APUS tree. But I don't think it's feasible for all graphics hardware.
That's not really true: you didn't fake a PCI bus, you implemented access to
the existing PCI bus on your PPC board.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Geert U. <ge...@li...> - 2000-09-25 12:47:08
|
On Sat, 23 Sep 2000, Christian T. Steigies wrote:
> On Fri, Sep 22, 2000 at 08:37:33PM +0200, Michael Schmitz wrote:
> > I know just barely enough to screw up a xfree build, and I don't have a
> > fast m68k for builds. Just in case you were about to ask.
> Well, ask me, I know barely enough to circumvent the glitches in the debian
> package to make 3.3.6 build.
>
> Ok, here comes the problem. I made patches for two Imakefile errors, build
> fails now here:
>
> gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy -Wl,-rpath-link,../../../../../exports/lib
> pcitweak.o: In function `main':
> pcitweak.o(.text+0x138): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci'
> pcitweak.o(.text+0x2b8): undefined reference to `pciTag'
> pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte'
> pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord'
> pcitweak.o(.text+0x306): undefined reference to `pciReadLong'
> pcitweak.o(.text+0x338): undefined reference to `pciWriteByte'
> pcitweak.o(.text+0x350): undefined reference to `pciWriteWord'
> pcitweak.o(.text+0x360): undefined reference to `pciWriteLong'
> collect2: ld returned 1 exit status
> make[7]: *** [pcitweak] Error 1
> make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc'
>
> In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus
> some *Pci.c files for several arches exist, but none for m68k. The files
> say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only
> have /proc/bus/zorro, but not pci... so maybe it would not make sense to add
> m68k to the Imakefile?
/proc/bus/pci is present only on a box that actually has PCI.
> However, without pci, I have some problems to get xfree4.0 to build, see
> error messages above. I think (anybody with a clue correct me please) that
> XF4.0 requires some pci functions, or some major rework in the (I)Makefiles
> and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci
> functions for m68k) or maybe even a patch, I'd be happy to hear about it.
Since some m68k boxes have PCI, just clone (or enable) the code that is used
on other Linux platforms. If /proc/bus/pci is not present, that code should
notice and decide there are no PCI devices. If it doesn't the PCI code in
XFree86 is broken.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X