Re: [linux-fbdev] Matrox and XFree86 4.0.2 update
On Wed, 24 Jan 2001, Petr Vandrovec wrote: > > On 24 Jan 01 at 11:11, Ani Joshi wrote: > > > I recently ran into an issue with the matroxfb driver and XFree86 4.0.2's > > matrox driver. Sometime in the past someone decided to use BE > > register access in matroxfb for BE machines, while this is probably The > > Right Way, it produces problems in X. I can use BE register access > > macro's in X but it was causing problems with the engine, perhaps some DMA > > issue although the dma BE bits are on. > > Using big-endian on PPC was required by PPC users for compatibility with > existing XF[86][68]_FBDev servers. Are you sure that there are no problems > otherwise, and that it works correctly on all PReP/CHRP/ architectures? Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where accelerated for matrox, other libs (SDL etc) that have accel for matroxfb don't work correctly for ppc either. Changing the endian to little is the *right* thing, big-endian mode doesn't offer us anything beyond problems in matroxfb 8/16 bit accesses become a nightmare there... Kostas
Re: [linux-fbdev] Matrox and XFree86 4.0.2 update
On Thu, 25 Jan 2001, Geert Uytterhoeven wrote:
> On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
> > On Wed, 24 Jan 2001, Petr Vandrovec wrote:
> >
> > Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
> > accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
> > don't work correctly for ppc either.
>
> XF68_FBDev is accelerated for matroxfb, at least on the PPC platform.
Ops i forgot about it, it will be easy to change it though, although
backwards compatibility will be a nightmare :(
> > Changing the endian to little is the *right* thing, big-endian mode doesn't
> > offer us anything beyond problems in matroxfb 8/16 bit accesses become a
> > nightmare there...
>
> 8/16 bit accesses? I assume you're talking about the frame buffer, not about
> the register accesses?
No i am talking about register accesses, for example
the mga driver in xfree86 uses
#define MGAISBUSY() (INREG8(MGAREG_Status + 2) & 0x01)
SDL uses
#define mga_wait(space) { \
while ( mga_in8(MGAREG_FIFOSTATUS) < space ); \
}
Both will fail under big-endian mode in PPC, the addressing is changed
so you have to use something like *(addr + (3-addr%4) to get the right
byte (i hope i got it right, its still early here)
> Currently XF68_FBDev needs a big-endian frame buffer on big-endian machines.
And i don't expect it to change ;P
Kostas
Re: XFree86 4.1.0: call for help
On Fri, 1 Jun 2001, Michel Dänzer wrote:
>
> Anton Blanchard wrote:
>
> > > - r128 doesn't work without UseFBDev at least on Pismos (I suspect all
> > > UniNorth Macs) because we're now trying to do ISA I/O with the help of a
> > > new system call, but the server crashes. It works fine on those machines
> > > without it, so what would we lose by disabling it in r128 #ifdef
> > > __powerpc__ ? Or what would be a better way to determine if it should be
> > > used or not?
> >
> > What system call is this?
>
> __NR_pciconfig_iobase
>
> Another approach might be to make it only return an ioBase for known working
> configurations, is that feasible?
We need a way to use multiple ioBases from inside xfree to fix the problem.
The best solution will be to disable ISA I/O for now and get a better fix
later on.
#ifdef __powerpc__ shouldn't be used inside the driver (at least in this
case) Its a Linux/ppc problem there is no need to criple the other ppc
platforms.
> > Do you know if the patch by davem to make X mmap("/proc/bus/pci/...") has
> > made it into 4.1.0? It makes life a lot easier for people with non
> > transparent PCI buses (at the moment I hardwire the offsets in for my
> > RS6000s).
>
> Possible, I see a number of PCI patches where he was involved, however they're
> all for SPARC and I'm afraid it's too late to adapt it for PPC for 4.1.0 .
Hmm i'll take a look at this patches, but i doubt that they will help with
the ISA I/O problem unless we change the way inb/outb work in the Xserver.
btw mmap("/proc/bus/pci/...") was added around 2.4.4 right ?
Kostas
Re: XFree86 4.1.0: call for help
On Fri, 1 Jun 2001, Ani Joshi wrote: > > > On Fri, 1 Jun 2001, Kostas Gewrgiou wrote: > > > > __NR_pciconfig_iobase > > > > > > Another approach might be to make it only return an ioBase for known > > > working > > > configurations, is that feasible? > > > > We need a way to use multiple ioBases from inside xfree to fix the problem. > > The best solution will be to disable ISA I/O for now and get a better fix > > later on. > > No, that's not the solution. The solution is to get the kernel to return > the *correct* iobase for the sepecific devfn, right now it returns one for > any and all pci devices. Since these strange UniN boards have multiple > bases, it should take into consideration the devfn (which it currently > ignores totally). > > Michel, find out your 2 (or 3?) iobases and try each one (hardcode it in > X, set it for ioBase_phys) and see which one works. When you find the > right one, add that to the kernel syscall, or find a generic way to find > the mask which sets those on that bus apart from others. > And what will happen if someone has a second card in the pci bus ? IO will still end up in the wrong place. We *need* a way to handle more than one ioBase otherwise will get in trouble. Kostas
Re: XFree86 4.1.0: call for help
On Tue, 19 Jun 2001, Ani Joshi wrote: > > > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote: > > > > > That would be nice, unfortunately it doesn't. For the record, here's the > > patch > > against xf-4_1-branch I tested: > > > Please try the attached patch. This fixes the problem on PCI machines and > could possibly fix yours too. > > It is against the stock 4.1.0 driver. > It will probably work for us, but it can't go in the XFree code the problem is linux/ppc specific and has to be fixed in the os specific part of the code. LynxOS/Pmax handle the ioBase problem (only the first bridge is supported there) and i assume that they need the vga font restore code. The #ifdef __powerpc__ isn't right (and we can't use os specific code in the drivers) so the fix has to go in another layer, crippling another os to fix our problems isn't the right solution. Kostas
Re: XFree86 4.1.0: call for help
On Wed, 20 Jun 2001, Michel Dänzer wrote: > Kostas Gewrgiou wrote: > > > > On Tue, 19 Jun 2001, Ani Joshi wrote: > > > > > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote: > > > > > > > That would be nice, unfortunately it doesn't. For the record, here's the > > > > patch against xf-4_1-branch I tested: > > > > > > > > > Please try the attached patch. This fixes the problem on PCI machines and > > > could possibly fix yours too. > > > > > > It is against the stock 4.1.0 driver. > > It works BTW. > > It will probably work for us, but it can't go in the XFree code > > the problem is linux/ppc specific and has to be fixed in the > > os specific part of the code. LynxOS/Pmax handle the > > ioBase problem (only the first bridge is supported there) and > > i assume that they need the vga font restore code. > > Why don't we need that and colormap anyway? Since fbdev is handling the console there is no need to restore vga fonts/colormap (i don't know if it is possible to run vgacon under some of the ibm machines, if yes then it is needed there) > > The #ifdef __powerpc__ isn't right (and we can't use os specific > > code in the drivers) so the fix has to go in another layer, > > crippling another os to fix our problems isn't the right solution. > > So, what can we do? We can't put arch or OS specific code to handle this in > vgaHW either. Maybe it's really best to handle it in the kernel? Everything that is os/arch specific more or less goes in xfree86/os-support adding something like xf86isIOAvailable(device/screen/whatever) is what we need. We still need to workout a way to handle multiple ioBases btw, there are other paths in the code that will do io in the wrong base and we need to handle this. Anyone with a second card in the pci bus will end up getting the isa io access for the agp card in the wrong card and thats not what we want. Kostas
Re: XFree86 4.1.0: call for help
On Wed, 20 Jun 2001, Michel Dänzer wrote: > Kostas Gewrgiou wrote: > > > > Since fbdev is handling the console there is no need to restore > > vga fonts/colormap (i don't know if it is possible to run vgacon > > under some of the ibm machines, if yes then it is needed there) > > That's my point, either we don't need anything anywhere (we don't need to save > the VGA mode with fbcon) or we need nothing on some machines and everything on > others. Saving and restoring only part of the VGA context doesn't make sense > to me. Hmm you have a point there, i have a feeling that the text/colormap was not crasing in the isa i/o access but in the isa mem ones, (we mmap 0xA, i wonder what lives there since isa mem definitely isn't) > > > So, what can we do? We can't put arch or OS specific code to handle this > > > in vgaHW either. Maybe it's really best to handle it in the kernel? > > > > Everything that is os/arch specific more or less goes in xfree86/os-support > > adding something like xf86isIOAvailable(device/screen/whatever) is what we > > need. > > Which won't work without kernel assistance, will it? So we could as well just > let the existing syscall handle everything. We don't need any more kernel assistance, just to fix the syscall to return an error for the AGP bus of Uni-N if we can't do any io there. The existing syscall can't handle everything as we use it right now, we only call it to get the ioBase for the first bus/device/function and we use this ioBase for *all* the cards that XFree is handling!!! The base that we get might have nothing to do with the base of the card that we use... > > We still need to workout a way to handle multiple ioBases btw, there are > > other paths in the code that will do io in the wrong base and we need > > to handle this. Anyone with a second card in the pci bus will end up > > getting the isa io access for the agp card in the wrong card and thats not > > what we want. > > Yup, but that's for 4.2 at the earliest... Since 4.1 went out broken we can't do much now, the best solution will be to disable the ioctl (since we don't get the right base anyway) Kostas
Re: XFree86 4.1.0: call for help
On Wed, 20 Jun 2001, Ani Joshi wrote:
>
>
> On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
>
> > The #ifdef __powerpc__ isn't right (and we can't use os specific
> > code in the drivers) so the fix has to go in another layer,
> > crippling another os to fix our problems isn't the right solution.
>
> Well, that's not really true. There's already lots of os specific code
> in drivers, look at fbdevhw for instance. Anyhow, the patch was for
> testing purposes, the real fix is to vgaHW and #undef'ing NEED_SAVED_CMAP.
>
Well the PReP people use the vga driver from what i heard (with hardcoded
values for isa io/mem) and they will need this part of the code i imagine.
I think that the crash in vgaHW is because of isa mem accesses, if this is
the case a better fix will be to mmap the right memory range for the
machines that have one and to handle the lack of one in pmacs.
Maybe something like the following in lnx_video.c will help
mapVidMem(int ScreenNum, unsigned long Base, unsigned long Size, int flags)
{
#if defined(__powerpc__)
if(Base < 0xff) {
SYSCALL(isa_mem_base = syscall(__NR_pciconfig_iobase, IOBASE_ISA_MEM, 0, 0));
if(isa_mem_base != -1) {
Base += isa_mem_base;
} else {
/* Not sure how to handle this maybe return some malloced memory ? /*
}
}
#endif
...
}
Kostas
Re: XFree86 4.1.0: call for help
On Wed, 20 Jun 2001 [EMAIL PROTECTED] wrote: > >We don't need any more kernel assistance, just to fix the syscall to > >return an error for the AGP bus of Uni-N if we can't do any io there. > > We can do _IO_, not ISA mem. Some cards require IOs accesses to > some VGA registers so we need the syscall to work. IOs are indeed > possible on all the UniNorth busses. Hmm i thought that we were getting the base for the pci bus not the agp in this case. > >Since 4.1 went out broken we can't do much now, the best solution will > >be to disable the ioctl (since we don't get the right base anyway) > > How ? If you get base for bus 0, you'll get the AGP which is what > you are looking for in this case. In this case yes but the code asks blindly for the base of bus 0, the card that is used might be anywhere though. Kostas
Re: Bugs in xfree68 that made it fail with jdk 1.2.1 found and fixed (fwd)
On Tue, 17 Aug 1999, Geert Uytterhoeven wrote: > > Anybody who'd care to try? I just erased my XFree86 3.3.x tree. > > BTW, I'm always willing to test a glibc-2.1 binary :-) > I had to erase my build of 3.9.15x to make space for the 3.3.x build *sigh* :( I'll have a binary in a few hours if you are intrested (Builds take a looong time in my [EMAIL PROTECTED]). I have to see if i can fix the no video drivers and the Modes "default" case first (and write a cleaner patch ;). Kostas Gewrgiou. PS> if i could fix the acceleration problems in my aty mach64gx also i'll be a happy man, too slow without accel too much noise with accel :(
Re: Bugs in xfree68 that made it fail with jdk 1.2.1 found and fixed (fwd)
On Thu, 19 Aug 1999, Geert Uytterhoeven wrote:
>
> On Tue, 17 Aug 1999, Kostas Gewrgiou wrote:
> > On Tue, 17 Aug 1999, Geert Uytterhoeven wrote:
> > > Anybody who'd care to try? I just erased my XFree86 3.3.x tree.
> > >
> > > BTW, I'm always willing to test a glibc-2.1 binary :-)
> > >
> >
> > I had to erase my build of 3.9.15x to make space for the 3.3.x build
> > *sigh* :(
> > I'll have a binary in a few hours if you are intrested (Builds take a looong
> > time in my [EMAIL PROTECTED]). I have to see if i can fix the no video
> > drivers and the
> > Modes "default" case first (and write a cleaner patch ;).
>
> I'm interested for sure!
>
> Greetings,
>
> Geert
>
> --
> Geert Uytterhoeven [EMAIL PROTECTED]
> Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
> Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
>
>
Test binary at ftp://idd-01.imbc.gr/pub/XF68_FBDev.bz2
depth 15 works (requires a Depth 15 entry in XF68Config)
the XFree86-VidModeExtension is also working same with xvidtune..
I haven't tested it at all with no video drivers or with no modes set in
the config (its probably broken there), i'll do proper fixes in the next
couple of days but feel free to test it now if you want.
Kostas.
Re: Screenblank powerdown LCD display?
On Wed, 8 Sep 1999, Benjamin Herrenschmidt wrote: > On Tue, Sep 7, 1999, John Whitley <[EMAIL PROTECTED]> wrote: > > >Hmm.. no go. I'm using frame buffer acceleration in combination with > >the ATI Rage LT Pro in my PB G3/400, and XF68_FBDev on top of that. > > > >Relevant output of 'xset q': > > > >Screen Saver: > > prefer blanking: yesallow exposures: yes > >[.. deletia ...] > >DPMS (Energy Star): > > Display is not capable of DPMS > > > >I have tried using the "setvesablank" program, with no effect. > >All the screen does is black out, but not power down. > At the moment XF68_FBDev doesn't support DPMS, it should be easy to add support for it though. I am not sure if Xpmac supports it either. Kostas Gewrgiou > You should check what's going on in your kernel. I beleive you are not > using "no video driver" in BootX ? (You should not be using that). > Normally, in drivers/video/atyfb, there should be some code for handling > backlight in the screen blanking function. > Is your kernel compiled with the option for PowerBook support ? > > -- >Perso. e-mail: <mailto:[EMAIL PROTECTED]> >Work e-mail: <mailto:[EMAIL PROTECTED]> > BenH. Web : <http://calvaweb.calvacom.fr/bh40/> >
Re: where is xfree?
On Thu, 30 Sep 1999, Geert Uytterhoeven wrote: > On Thu, 30 Sep 1999, Sven LUTHER wrote: > > On Fri, Sep 24, 1999 at 11:34:04AM -0700, Tom Rini wrote: > > > On Fri, 24 Sep 1999, Sven LUTHER wrote: > > > Right now, I build X w/ the following patches (For FBDev): > > > XFree86-3.3.3.1-fbdev_dc.patch (DC hack to fbdev/fbdev.c, colormap fix) > > > XFree86-3.3.3.1-fbdev_dga.patch (Enable some DGA extentions, xawtv works) > > > XFree86-3.3.5-fbdev_15.patch: This does a few things good and bad. The > > > depth line in XF86Config should now be the values of red, green and blue > > > that the fb uses. ie "Depth 16" is now 16 or 15, depending on what the > > > values add up to, and "Depth 32" should always be 24 (8+8+8). Kevin > > > Hendricks is responsible for this one and can explain better. > > > XFree86-3.3.5-fbdev_machutil.patch: I posted this one a while back, this > > > adds in LinkSourceFile(mach64util.h...) to the mach64 dir, and #ifndef > > > powerpc's regw/etc in mach64util.h > > > > Do you want them integrated in a future version of upstream X ? i am X team > > member, and can do it. Will have to do a bit of testing and building myself > > before that though. > > Is the `SEGV on incorrect depth' problem fixed? I have no problems at all with > `Depth' having to be 15 or 24 (which is more correct), but I'd like to see a > decent error message instead of a SEGV when people try depth 16 or 32. > > Greetings, > > Geert Nope it isn't fixed yet :( i'll take a look at it once i have some free time (around next week) unless someone beats me to it. BTW is there any way to get the fb_info struct from userland ? I would like to add DPMS support in X server Kostas Gewrgiou
MySQL at Linux/PPC
After looking at Bug#: 5732 in RedHat's bugzilla, (http://developer.redhat.com/bugzilla/show_bug.cgi?id=5732) i found out why enabling LFS makes a bad mysql binary, quoting from the description of the patch bug: The configure scripts of patch-2.5 detect the LFS support in glibc-2.1, but due to the lack of a definition of _GNU_SOURCE, no prototypes for fseeko are declared. That way the compiler thinks fseeko is taking a 32bit argument for the offset, when in reality it takes a 64bit offset. After compiling MySQL with -D_GNU_SOURCE (with LFS enabled) the problems went away, i am not sure if defining _LARGEFILE_SOURCE is supposed to give the fseeko declarations but if it is then its a bug in the glibc headers. Kostas Gewrgiou.
Re: Vodoo 2/3 (& other video questions)
On Mon, 22 Nov 1999, Sven LUTHER wrote: > On Sun, Nov 21, 1999 at 05:11:58PM -0600, Kevin Puetz wrote: > > How is the outlook for 3d accelleration on debian-ppc? > > I've found some attractive deals on voodoo 2 and 3, and wonder whether I > > can expect (in the moderately near future) to see either or both of these > > cards supported. > > I know nothing about the vodoo stuff, but ... > > > I saw (on Slashdot) that the voodoo3's drivers and DRI (for Xfree 4.0) > > modules were open-sourced - but I don't know if the code looks portable, > > or if Xfree 4 even works on PPC. So the V3 might show some promise, but > > Xfree 3.9.16 works perfectly well on ppc. You have to disable the INT10 stuff > in the i386 emulator for reading graphic boards bioses for now, since it is > i386 only until someone port it to the other arches (it is rumored to have > worked on alphas in the past), or adapt the ppc assembly emulator from gabriel > paubert. > > This will permit you (in theory) to use any graphic board in your powermac. > I haven't looked at the INT10 stuff yet but it wont help us with OF based cards in any case. The cards with fbdev support work fine without acceleration. For acceleration the driver needs to support fbdev right now only the mga, glint and nv drivers have support for it. I am not sure about the status of the nv/glint driver but the matrox one has some endian problems i started working on it a few days ago and i hope i'll have it finished this week. > You can get a primitive tarball from : > > * > http://n.ethz.ch/student/daenzerm/download/XFree86-3.9.16c-pm2-glibc2.1.tar.g > > I wanted to make a debian package (xserver-3.9 or something like that) > containing this stuff, or at least something similar, but didn't get the time > for it, maybe for christmas ... > > As for general Xfree4.0/DRI support, best is to get matrox/tnt2 based boards, > but rage128 board seems to be supported also. > Take a look at http://glx.on.openprojects.net also, they support matrox/nvidia and work has started for ati rage cards too, i am not sure if they work under ppc though (since i don't have a 3d card :( ). About DRI i heard that it doesn't work with fbcon but i might be wrong there. > You would need mesa3.1 also and the glx stuff. > > Friendly, > > Sven LUTHER > > Kostas Gewrgiou
Re: Vodoo 2/3 (& other video questions)
On Sat, 27 Nov 1999, Michel [iso-8859-1] Dδnzer wrote: > Kostas Gewrgiou wrote: > > > I am not sure about the status of the nv/glint driver but the matrox one has > > some endian problems i started working on it a few days ago and i hope i'll > > have it finished this week. > > > There are endian problems in the glint driver (and maybe even in the general > code) as well :( > > Maybe your work on mga could also help for glint? Nope i am afraid it wont help at all the changes i've done so far are mga specific, mostly setting up the registers in the matrox to do the the endian conversions. My problem right now is the CPUToScreenColorExpandFill related functions that don't work right maybe the problem is in a higher level i didn't had enough time to track it down though :( I got a voodoo card last night so i'll be looking at it too :) Kostas Gewrgiou > > > Michel > > > -- > Five days a week my body is a temple. The other two, it's an amusement park. > __ > Michel Dδnzer /// [EMAIL PROTECTED] > __ /// AmigaOS/Linux(Debian/PPC) > Student of computer science at the \\\/// Team *AMIGA* ICQ #: 5675698 > Swiss Federal Institute of Technology \\\/ AUGS member #163 IRC: CoOpER > >
Re: Announcing: XFree86 Xserver accelerated for Rage 128 from XFree86 3.9.17
On Sun, 16 Jan 2000, Geert Uytterhoeven wrote: > On Sun, 16 Jan 2000, Kevin Puetz wrote: > > [EMAIL PROTECTED] said: > > > Announcing: XFree86 r128 Xserver (version 1) from the pre-XFree4.0 > > > (based on xfree86 version 3.9.17) distribution from the XFree86 org. > > > > > This Xserver has full Rage 128 acceleration and supports both hardware > > > and software cursors. In x11perf testing, this Xserver beats Xpmac > > > (currently revision 8) on most performance measures (but not all). > > > > Wohoo! mozilla last night (I have a working build!) Xfree 3.9 today! > > Sorry bout the excitability - the number of Linux-not-PPC packages was > > beginning to concern me, but they're getting fixed in droves. > > > > Presumably, then, this works only on Rage 128? I've still got a Rage II+ > > :-*. > > Or is it just not accelerated much (or at all) then? I'm probably not going > > to > > switch (unless you want a tested with an older machine, Beige G3 Rev1 > > Desktop), but I'm curious about the support for somewhat older video cards. > > We just need someone to make the Mach64 stuff in 3.9.x work with atyfb as > well... Kevin proved that such things can be done :-) > It is possible, but since the mach64 driver in 3.9.x doesn't have acceleration yet it won't offer anything more than the fbdev driver. Once acceleration is there i am sure that one of us will do it :). Note also that the mga/glint drivers support fbdev as well. Anyone willing to add support for the mac only cards platinum/control etc ? Kostas
Re: Announcing: XFree86 Xserver accelerated for Rage 128 from XFree86 3.9.17
On Mon, 17 Jan 2000, Geert Uytterhoeven wrote: > On Mon, 17 Jan 2000, Benjamin Herrenschmidt wrote: > > On Mon, Jan 17, 2000, Kostas Gewrgiou <[EMAIL PROTECTED]> wrote: > > > It is possible, but since the mach64 driver in 3.9.x doesn't have > > >acceleration > > >yet it won't offer anything more than the fbdev driver. Once acceleration > > >is > > >there i am sure that one of us will do it :). Note also that the mga/glint > > >drivers support fbdev as well. Anyone willing to add support for the mac > > >only > > >cards platinum/control etc ? > > > > There is support for mach64 accel in Geert's FBDev, I think. Isn't it > > possible to port this using Kevin Rage128 stuff as a framework ? > > 3.3.x differs a lot from 3.9.x. > > BTW, I thought the PI guys added accel support for Mach64 to 3.9.x some months > ago... > Nope the ati driver in 3.9.x doesn't have acceleration, from the xfree mailing lists it seems that accel is ready (or almost ready) and patches will be submitted soon. The driver in 3.9.x supports both mach32 and mach64 from what i can see, and even without accel the sources are about 600k so porting it to fbdev *might* not be easy :(. Kostas Gewrgiou
Re: Sound woes
On Thu, 3 Feb 2000, David Given wrote: > I'm running potato Debian on a boring beige 8200/120, using the DMA sound > driver compiled into kernel version 2.2.13. Now, it's mostly working very > well > --- the general sound quality is pretty good --- but I am having some > problems. > > You see, it claims to be OSS compatible. It's not particularly. It works okay > if I'm just streaming sound to it but if I try to do anything complex --- > like > running esd or xmms --- it's got a nasty tendency to fall over or lock up the > controlling process. > > Has anyone else met anything like this? I am having the same problem for some time now, i checked with strace and always the process is stuck in a write to /dev/dsp. Sending a signal to the process will restart the write (as expected) and it manages to write a few bytes before blocking again. If i remember correctly the problem started around 2.2.9/11 the awacs driver didn't had any changes at that time so it must be something else. There are other people having the same problem too.. Kostas
Re: 3.9.18 PPC X server
On Thu, 24 Feb 2000, Geert Uytterhoeven wrote:
> On Wed, 23 Feb 2000, Michel [iso-8859-1] Dδnzer wrote:
> > This fixes quite some bugs, give it a try if you've been deceived by
> > 3.9.17f,
> > especially as the tarballs are smaller now :)
>
> I tried it on my CHRP-box with plain fbdev (on atyfb).
>
> It locks up my machine, right after `Loading
> /usr/X11R6/lib/modules/libshadowfb.a' (I was logged in remotely). The screen
> got black, and the machine stops working. It still respond to ping and the
> Caps-Lock key toggles the Caps-Lock LED. I cannot change VCs. Ssh no longer
> works, but if I telnet to port 22, I do get a `connected' message. So some
> things are still working. Does the X server try to mess with my PCI
> devices/resources?
>
Yes it does play with pci :( it will disable pci mem/io for all the pci
cards that its not using note that it will do that even for the card that
you use with fbdev since it considers it unused unless you use the
BusID "PCI:x:x:x" option.
I reported this in the xfree list a few days ago.
Kostas
>
> Gr{oetje,eeting}s,
>
> Geert
Re: 3.9.18 PPC X server
On Fri, 25 Feb 2000, Michel Dδnzer wrote: > > > Geert Uytterhoeven wrote: > > > > On Wed, 23 Feb 2000, Michel [iso-8859-1] Dδnzer wrote: > > > This fixes quite some bugs, give it a try if you've been deceived by > > > 3.9.17f, > > > especially as the tarballs are smaller now :) > > > > I tried it on my CHRP-box with plain fbdev (on atyfb). > > > > It locks up my machine, right after `Loading > > /usr/X11R6/lib/modules/libshadowfb.a' (I was logged in remotely). The screen > > got black, and the machine stops working. It still respond to ping and the > > Caps-Lock key toggles the Caps-Lock LED. I cannot change VCs. Ssh no longer > > works, but if I telnet to port 22, I do get a `connected' message. So some > > things are still working. Does the X server try to mess with my PCI > > devices/resources? > > Yes, as Kostas pointed out, it does... > > Additionally, I only hacked up some PCI code originally intended for Alphas to > _build_ on APUS, it may only work here because APUS has no PCI... > > Kostas is working on it, and I'm confident he'll get it right. The Xserver by design disables the pci video cards its not using and there is not a simple way to know which pci card a given fbdev driver is using (Jeff Garzik suggested to use the smem_start/mmio_start values from fbdev to detect that which is the best we can do i suppose) Thats not going to solve the problems in a multihead system though imagine that you have a console running in one card and you start the xserver in the other, the xserver will disable the other card (since its not using it) and that will cause problems obviously. > > Michel >
Re: XFree86 4 phase2v5 available for powerpc
On Fri, 15 Sep 2000, Robert Ramiega wrote:
> Than i made just one thing: changed /etc/X11/Xserver to point to XFree86
> from the tarball and all started to work again.
> While using Xfree86 from debs i noticed this line in logfile:
>
> (II) Defaulting to XFree86/Linux keycode handling.
>
> Could this cause problems ? If so how can I (help) fix that ?
>
Yeap thats the problem, looking at Franz's patch it seems that if
keyboard_sends_linux_keycodes doesn't exist, the server assumes AT keycodes.
I am not sure how to handle APUS as well, even the pmac test through xkb
will only work if xkb is enabled (not always the case), i think it should
be better to handle all the cases through the config file although it will
make it harder for the users :(
Kostas
FILE *f;
f = fopen("/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes","r");
if (f)
{
if (fgetc(f) != '0')
{
xf86Msg (X_INFO, "Using XFree86/Linux keycode handling.\n");
kbdStdKeycodes = 1;
}
else
{
xf86Msg (X_INFO, "Using deprecated Macintosh keycodes.\n");
kbdStdKeycodes = 0;
}
fclose(f);
}
else
{
if (xf86Info.xkbkeycodes && !strcmp(xf86Info.xkbkeycodes, "macintosh"))
{
xf86Msg (X_INFO, "XkbKeycodes setting is \"%s\", using deprecated
Macintosh keycodes.\n", xf86Info.xkbkeycodes);
kbdStdKeycodes = 0;
}
else if (xf86Info.xkbmodel && !strcmp(xf86Info.xkbmodel, "macintosh_old"))
{
xf86Msg (X_INFO, "XkbModel setting is \"%s\", using deprecated Macintosh
keycodes.\n", xf86Info.xkbmodel);
kbdStdKeycodes = 0;
}
else
{
xf86Msg (X_INFO, "Defaulting to XFree86/Linux keycode handling.\n");
kbdStdKeycodes = 1;
}
}
.
Re: XFree86 4 phase2v5 available for powerpc
On Fri, 15 Sep 2000, Michael Schmitz wrote: > > >Yeap thats the problem, looking at Franz's patch it seems that if > > > keyboard_sends_linux_keycodes doesn't exist, the server assumes AT > > > keycodes. > > > I am not sure how to handle APUS as well, even the pmac test through xkb > > > will only work if xkb is enabled (not always the case), i think it should > > > be better to handle all the cases through the config file although it will > > > make it harder for the users :( > > > > Erm... this doesn't make sense to me. On powerpc, if the file does not > > exist, shouldn't we maintain the old behavior? > > Feel free to discuss this with Franz. I've had my fruitless discussion > about keeping backwards compatibility already (about adbmouse and mouse > button emulation), I won't repeat it. > > To be fair: implementing/backporting the new input layer code for APUS > would be another solution to this problem. > It's a bug not a feature ;P obviously the default should be the old behavior if keyboard_sends_linux_keycodes isn't there, we do want backwards compatibility in the Xserver and i don't think that anyone disagrees with that. Note also that the old behavior wasn't perfect, we have archs that were using the at keycodes before the input layer so we just can't assume adb if keyboard_sends_linux_keycodes isn't there :( Kostas
Re: ggi debs for testing
I did built libgii/libggi/svgalib4ggi rpms a week ago (under glibc1.99) ggi apps run fine under X, dga support seems broken though. Under fb they work BUT resolution changes result in invalid scan range from my monitor, if you are already in the right res ggi programs run fine. i spend a few hours playing heretic/doom in the console using both ggi and svga/ggi with no problems. Kostas Gewrgiou On Tue, 27 Apr 1999, Konstantinos Margaritis wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Tue, 27 Apr 1999, Michel Dδnzer wrote: > >Konstantinos Margaritis wrote: > > > >> I have prepared some debs for libggi (990329), svgalib4ggi (990330) and > >> mesa3+ggi (powerpc of course). However, testing them proved futile, as my > >> fb > >> is probably buggy (valkyrie, I wish I had the time to check the kernel > >> source). However, I don't feel it's ggi's fault and I would like to have > >> the > >> packages ready for testing before upload. > > > >I tested them last weekend, installed them and ran the 'monitest' (or > >similar) > >command, and it hanged my kernel :( Sorry, I didn't have time to investigate > >further. > > >I'm using the pm2fb framebuffer on my Amiga. > > seems that ggi is not problematic only for me. I'll check the new ones. > it looks as if the fb is the problem though. ggi for X works just fine. > btw, which kernel are you using? > > - -- > Konstantinos Margaritis >
Re: ggi debs for testing
On Wed, 28 Apr 1999, Konstantinos Margaritis wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Wed, 28 Apr 1999, Kostas Gewrgiou wrote: > >I did built libgii/libggi/svgalib4ggi rpms a week ago (under glibc1.99) > >ggi apps run fine under X, dga support seems broken though. > >Under fb they work BUT resolution changes result in invalid scan range > >from my monitor, if you are already in the right res ggi programs run > >fine. i spend a few hours playing heretic/doom in the console using > >both ggi and svga/ggi with no problems. > > That's good news. At least now we know that ggi can work on fbdev/powerpc. > Does the rpm include any specific powerpc/glibc 1.99 patches? Where is the > .src.rpm? > Also, what kernel/compiler/display(mach64,control,platinum, etc.)? > Ops sorry i forgot to give more info, i got the source rpms from ftp://atrey.karlin.mff.cuni.cz/pub/local/miri/ggi/2.0b2/ (link from the ggi homepage) i didn't had to do any changes in the source, i only removed the parts that don't built (vgagl needs glide) in the %files section of the spec file. My kernel was around 2.2.4/5 at that time, latest version of egcs (1.1.2), display is atyfb (Mach64 GX). Kostas Gewrgiou PS> I plan to write some ggi apps some time next week so i'll take a closer look at it. > - -- > Konstantinos Margaritis > > -BEGIN PGP SIGNATURE- > Version: 2.6.3ia > Charset: noconv > > iQCVAwUBNyb74valfJok8qABAQHuCAQApsi76zptabMg1jf8puWXHlJZ6Ze7BMGd > vhwlXxYFq3lD9OJN+IJw3gqqXdQG3tKWGm5bwt+Hvp3tqk5FHTyV3SkYBvAZw5D0 > T+KvMREj7S6WozTCUYzg2zo7QpbXQLMqtriRGCW2MXKfIeeknC5bHDCNBWhtIkQV > zBEbSE9mpxg= > =Orxj > -END PGP SIGNATURE- >
Re: XForms ?
I think that linuxppc R5 had rpms for xforms at some point but i might be wrong. Kostas Gewrgiou On Wed, 28 Apr 1999, Daniel Jacobowitz wrote: > On Wed, Apr 28, 1999 at 05:44:19PM +0200, Hubert Figuiere wrote: > > Where can I find XForms for Linux Debian/PPC (ie compatible with > > glibc2.1) > > I couldn't find it, and source code is NOT available. I'm missing > > LyX very much. > > > > You can't. > > Pity, that; it may be non-free, but it's still a fairly nice toolkit. > > Dan > > /\ /\ > | Daniel Jacobowitz|__| CMU, CS class of 2002 | > | Debian GNU/Linux Developer__ Part-Time Systems Programmer | > | [EMAIL PROTECTED] | |[EMAIL PROTECTED] | > \/ \/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
