Re: [Dri-devel] Mach64: vt switching
El Vie 26 Oct 2001 22:11, Leif Delgass escribió: Manuel, the hang when switching back from a vt to X with Quake running hangs both in fullscreen and windowed mode (other GL apps like gears don't exhibit this problem, although there is initially some garbage at the top of the screen when returning to X). I'm sure you're right that it has to do with the locking (or lack thereof) in the enter/leaveVT. And with that I'm heading out, I'll try to do some more investigation tommorow... Well. I've written a pair of macros to interlock drm and Xdriver and used it in all the accelerated access from the XDriver. I've also used the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the aticonsole.c file. After this, we cannot enable 2D accelerated rendering yet, because the drm and mesa sides are not honouring this interlocking. This should be made when Frank has the new DMA API finished, because the points to lock will be less than now (I suppose that we only will need to lock the actual DMA transfers) because the DMAOUTREG is only going to append the register writes to a DMA buffer. So, I suppose that the EnterVT/LeaveVT bug is still here, because of a non locking DRM. Anyway, I tried to reenable 2D acceleration and run gears. The engine locked after trying to close gears, but the cursor still worked. My idea is updating the branch with this changes (still without reenabling the 2D acceleration) and Leif ones for the AGP corrections. Leif, I've (#ifdef)ed the AGP code as you told me, but I think that your host.def changes are good for the mach64 branch (disabling the Glide dependencies and enabling builds of DRM drivers) and I plan update it too. Another secondary issue: I'm still have a problem compiling the branch: The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of shared libraries and I think that there is no need to build this utilities in the DRI context. So, I'm also going to add another change to the host.def file: -#define BuildXFree86ConfigTools YES +#define BuildXFree86ConfigTools NO In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable this tools build: ... #if !BuildServersOnly || BuildXFree86ConfigTools XF86CFGDIRS = xf86cfg xf86config #endif ... and we will need less libraries. Finally, and to accelerate the build, the line: #define XF86CardDrivers tdfx i810 mga ati glint vga should be: #define XF86CardDrivers ati And perhaps: #define XFree86CustomVersion DRI trunk should be replaced by: #define XFree86CustomVersion DRI mach64 branch Do you agree ? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 2D driver
Hi everybody working on the Mach64 driver, I think it's really important for you to get in touch with the 2D driver maintainer, Marc Aurele La France [EMAIL PROTECTED]. First because he is the single most competent person about the 2D driver and probably about the Mach chips in general, second because he doesn't like other people messing with his code. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 2D driver
El Sáb 27 Oct 2001 16:08, Michel Dänzer escribió: Hi everybody working on the Mach64 driver, I think it's really important for you to get in touch with the 2D driver maintainer, Marc Aurele La France [EMAIL PROTECTED]. First because he is the single most competent person about the 2D driver and probably about the Mach chips in general, second because he doesn't like other people messing with his code. ;) Thanks Michel, for the advise. I thing that the best is wait for Frank to finish the DRM DMA API and then see if the locking is working fine. After this, we could present and explain to Marc Aurele the changes we have made to know his opinion about them. Anyway the changes in the 2D code are very few: 1.-Avoid changes in the GUI_CNTL for the fifo depth. Perhaps we could notify this issue to Marc and try to find another solution. 2.-Make the 2D accelerated functions honour the DRM locks. This is still work in progress and I think that we must wait after checking this code to disturb Marc about it. 3.-Make the LeaveVT and EnterVT honour the DRM locks. The same than the previous point. I think that there were no more changes but the initialization for DRI written by Gareth (that are new and not written by Marc) and the hacks disabling 2D acceleration that I hope we will be able to remove in short. Regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: locking, patch
First off, I messed up on the FIFO size defines in mach64_drv.h (drm kernel module), they should be: # define MACH64_CMDFIFO_SIZE_MASK 0x0003ul # define MACH64_CMDFIFO_SIZE_192 0xul # define MACH64_CMDFIFO_SIZE_128 0x0001ul # define MACH64_CMDFIFO_SIZE_64 0x0002ul I was mixing up my hex and binary, yikes! (at least 1 is always 1 so no harm done) Embarassing. Don't drink and code. Anyway... Well. I've written a pair of macros to interlock drm and Xdriver and used it in all the accelerated access from the XDriver. I've also used the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the aticonsole.c file. After this, we cannot enable 2D accelerated rendering yet, because the drm and mesa sides are not honouring this interlocking. This should be made when Frank has the new DMA API finished, because the points to lock will be less than now (I suppose that we only will need to lock the actual DMA transfers) because the DMAOUTREG is only going to append the register writes to a DMA buffer. So, I suppose that the EnterVT/LeaveVT bug is still here, because of a non locking DRM. What about mode switches? The mga and i810 drivers use DRILock/DRIUnlock in the ModeInit functions, and the r128/radeon drivers have a comment that says: /* FIXME? DRILock/DRIUnlock here? */ Anyway, I tried to reenable 2D acceleration and run gears. The engine locked after trying to close gears, but the cursor still worked. My idea is updating the branch with this changes (still without reenabling the 2D acceleration) and Leif ones for the AGP corrections. Leif, I've (#ifdef)ed the AGP code as you told me, but I think that your host.def changes are good for the mach64 branch (disabling the Glide dependencies and enabling builds of DRM drivers) and I plan update it too. Another secondary issue: I'm still have a problem compiling the branch: The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of shared libraries and I think that there is no need to build this utilities in the DRI context. So, I'm also going to add another change to the host.def file: -#define BuildXFree86ConfigTools YES +#define BuildXFree86ConfigTools NO In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable this tools build: ... #if !BuildServersOnly || BuildXFree86ConfigTools XF86CFGDIRS = xf86cfg xf86config #endif ... and we will need less libraries. Finally, and to accelerate the build, the line: #define XF86CardDrivers tdfx i810 mga ati glint vga should be: #define XF86CardDrivers ati And perhaps: #define XFree86CustomVersion DRI trunk should be replaced by: #define XFree86CustomVersion DRI mach64 branch Do you agree ? I think these changes are fine for the branch, it should speed up the build. We'll just need to make sure not to merge them to the trunk when the time comes. -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: locking, patch
El Sáb 27 Oct 2001 18:49, Leif Delgass escribió: First off, I messed up on the FIFO size defines in mach64_drv.h (drm kernel module), they should be: # define MACH64_CMDFIFO_SIZE_MASK 0x0003ul # define MACH64_CMDFIFO_SIZE_192 0xul # define MACH64_CMDFIFO_SIZE_128 0x0001ul # define MACH64_CMDFIFO_SIZE_64 0x0002ul I was mixing up my hex and binary, yikes! (at least 1 is always 1 so no harm done) Embarassing. Don't drink and code. Anyway... :-) Fixed. Well. I've written a pair of macros to interlock drm and Xdriver and used it in all the accelerated access from the XDriver. I've also used the DRILock/DRIUnlock API to lock the ATILeaveVT and ATIEnterVT in the aticonsole.c file. After this, we cannot enable 2D accelerated rendering yet, because the drm and mesa sides are not honouring this interlocking. This should be made when Frank has the new DMA API finished, because the points to lock will be less than now (I suppose that we only will need to lock the actual DMA transfers) because the DMAOUTREG is only going to append the register writes to a DMA buffer. So, I suppose that the EnterVT/LeaveVT bug is still here, because of a non locking DRM. What about mode switches? The mga and i810 drivers use DRILock/DRIUnlock in the ModeInit functions, and the r128/radeon drivers have a comment that says: /* FIXME? DRILock/DRIUnlock here? */ I don't know if it's necessary. Perhaps we could try to change the screen mode while running gears or Quake3. If the machine locks, then, it'll be necessary. ;-) Anyway, I tried to reenable 2D acceleration and run gears. The engine locked after trying to close gears, but the cursor still worked. My idea is updating the branch with this changes (still without reenabling the 2D acceleration) and Leif ones for the AGP corrections. Leif, I've (#ifdef)ed the AGP code as you told me, but I think that your host.def changes are good for the mach64 branch (disabling the Glide dependencies and enabling builds of DRM drivers) and I plan update it too. Another secondary issue: I'm still have a problem compiling the branch: The xf86cfg directory in programs/Xserver/hw/xfree86 needs a lot of shared libraries and I think that there is no need to build this utilities in the DRI context. So, I'm also going to add another change to the host.def file: -#define BuildXFree86ConfigTools YES +#define BuildXFree86ConfigTools NO In this way, the Imakefile in programs/Xserver/hw/xfree86 will disable this tools build: ... #if !BuildServersOnly || BuildXFree86ConfigTools XF86CFGDIRS = xf86cfg xf86config #endif ... and we will need less libraries. Finally, and to accelerate the build, the line: #define XF86CardDrivers tdfx i810 mga ati glint vga should be: #define XF86CardDrivers ati And perhaps: #define XFree86CustomVersion DRI trunk should be replaced by: #define XFree86CustomVersion DRI mach64 branch Do you agree ? I think these changes are fine for the branch, it should speed up the build. We'll just need to make sure not to merge them to the trunk when the time comes. Well, I think that we (or whoever that do it) don't even try to merge our host.def to the main trunk, it has nosense. I think that I will update the CVS branch this night. There aren't very important changes, but I think that it's better to have the branch as updated as possible. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 locking on mode switches
Well, I just got my box to hang hard (like with the vt switching) when running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes defined in my config and the hang happened when looping back to the original mode, i.e. the third switch), so I think the answer is yes, it needs locking. I really should use a journalling filesystem, all this fsck-ing is getting a bit tedious. ;) --Leif -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third switch), so I think the
answer is yes, it needs locking. I really should use a journalling
filesystem, all this fsck-ing is getting a bit tedious. ;)
OK. I have added the DRILock/Unlock to the AtiModeSet function in the
atimode.c file. I've added another condition (also to the locks in the
aticonsole.c file for vt changing) in this way:
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRILock(pScreen,0);
}
#endif
...
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRIUnlock(pScreen);
}
#endif
I think this is a better way because the code in aticonsole.c and atimode.c
is generic for all the ATI adapters, so we are restricting the checking to
the Mach64 chips greater than the GT that is the first one (if I'm not
mistaken) supporting 3D.
I'm also changing the related macros for locking the 2D accelerated functions.
--Leif
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third switch), so I think the
answer is yes, it needs locking. I really should use a journalling
filesystem, all this fsck-ing is getting a bit tedious. ;)
OK. I have added the DRILock/Unlock to the AtiModeSet function in the
atimode.c file. I've added another condition (also to the locks in the
aticonsole.c file for vt changing) in this way:
It looks like ATIEnter/LeaveVT calls ATIEnter/LeaveGraphics, which in turn
calls ATIModeSet. Won't this lead to trying to obtain a lock when the
lock is already secured? It might be better to put the lock in
aticonsole.c in the ATIModeSwitch function.
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRILock(pScreen,0);
}
#endif
...
#ifdef XF86DRI
if (pATI-Chip = ATI_CHIP_264GT
pATI-directRenderingEnabled)
{
DRIUnlock(pScreen);
}
#endif
I think this is a better way because the code in aticonsole.c and atimode.c
is generic for all the ATI adapters, so we are restricting the checking to
the Mach64 chips greater than the GT that is the first one (if I'm not
mistaken) supporting 3D.
Yep, that looks better.
I'm also changing the related macros for locking the 2D accelerated functions.
OK. I'm attaching a small patch that defines and uses a convenience macro
used by the other drm drivers (LOCK_TEST_WITH_RETURN). We can use this
when we add more ioctls. The patch also includes the FIFO size defines,
but you can just say no to that and delete the .rej file.
Another thing I noticed is that all the other 2D/dri drivers notify the
xf86 module loader about DRI/DRM symbols using [xf86]LoaderRefSymLists, in
addition to other symbols (see R128PreInit in r128_driver.c for an
example). I can't find anywhere that the ati/mach64 driver does this, but
it doesn't seem to be causing any problems.
On a totally unrelated note, do you know how to get etags to index KR
style functions like the ones in aticonsole.c?
--
Leif Delgass
m64-locking-macro.patch.gz
Re: [Dri-devel] Mach64 locking on mode switches
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió: On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 19:49, Leif Delgass escribió: Well, I just got my box to hang hard (like with the vt switching) when running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes defined in my config and the hang happened when looping back to the original mode, i.e. the third switch), so I think the answer is yes, it needs locking. I really should use a journalling filesystem, all this fsck-ing is getting a bit tedious. ;) OK. I have added the DRILock/Unlock to the AtiModeSet function in the atimode.c file. I've added another condition (also to the locks in the aticonsole.c file for vt changing) in this way: It looks like ATIEnter/LeaveVT calls ATIEnter/LeaveGraphics, which in turn calls ATIModeSet. Won't this lead to trying to obtain a lock when the lock is already secured? It might be better to put the lock in aticonsole.c in the ATIModeSwitch function. You are right, I was deadlocking the server. Anyway, the idea is that ATIModeSet has to Lock and Unlock, but ATIEnterVT(LeaveVT) has only to Unlock(Lock) the DRM. We could Lock/Unlock in ATISwitchMode, but I think that we are locking more that needed, because the ATIModeCalculate that is also called from ATISwitchMode doesn't need to be locked. I think that the better way to do this is: ATIEnterVT: Unlock at the end of the Function (to avoid interlocks) ATILeaveVT: Lock at the end of the Function (to avoid interlocks) ATIModeSet: Lock at the beginning and Unlock at the end. What do you thing about this? OK. I'm attaching a small patch that defines and uses a convenience macro used by the other drm drivers (LOCK_TEST_WITH_RETURN). We can use this when we add more ioctls. The patch also includes the FIFO size defines, but you can just say no to that and delete the .rej file. All right. I've commited the changes to the CVS branch yet, but I have to fix the deadlock you've found, so, I'll also send the changes you've sent me. On a totally unrelated note, do you know how to get etags to index KR style functions like the ones in aticonsole.c? No. Sorry. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 locking on mode switches
On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 21:40, Leif Delgass escribió: On Sat, 27 Oct 2001, Manuel Teira wrote: El Sáb 27 Oct 2001 19:49, Leif Delgass escribió: Well, I just got my box to hang hard (like with the vt switching) when running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes defined in my config and the hang happened when looping back to the original mode, i.e. the third switch), so I think the answer is yes, it needs locking. I really should use a journalling filesystem, all this fsck-ing is getting a bit tedious. ;) OK. I have added the DRILock/Unlock to the AtiModeSet function in the atimode.c file. I've added another condition (also to the locks in the aticonsole.c file for vt changing) in this way: It looks like ATIEnter/LeaveVT calls ATIEnter/LeaveGraphics, which in turn calls ATIModeSet. Won't this lead to trying to obtain a lock when the lock is already secured? It might be better to put the lock in aticonsole.c in the ATIModeSwitch function. You are right, I was deadlocking the server. Anyway, the idea is that ATIModeSet has to Lock and Unlock, but ATIEnterVT(LeaveVT) has only to Unlock(Lock) the DRM. We could Lock/Unlock in ATISwitchMode, but I think that we are locking more that needed, because the ATIModeCalculate that is also called from ATISwitchMode doesn't need to be locked. I think that the better way to do this is: ATIEnterVT: Unlock at the end of the Function (to avoid interlocks) ATILeaveVT: Lock at the end of the Function (to avoid interlocks) ATIModeSet: Lock at the beginning and Unlock at the end. What do you thing about this? Well, let's look at the sequence assuming what you suggest. This is as much for me to get it straight in my head as anything else... Xserver is running. We switch to text mode: 1. ATILeaveVT is called, which calls ATILeaveGraphics 2. ATIModeSave 3. ATIModeSet (DRILock,DRIUnlock) 4. ATILock, return from ATILeaveGraphics 5. DRILock I'm not sure it's worth unlocking just to lock again here. Text mode is running. We switch to graphics mode: 1. ATIEnterVT is called, which calls ATIEnterGraphics 2. ATIUnlock 3. ATIModeCalculate 4. ATIModeSave 5. ATIModeSet (DRILock,DRIUnlock), return from ATIEnterGraphics Oops!, at this point we still hold the DRILock, so again we'll be trying to lock twice, right? 6. DRIUnlock Here we've already unlocked. Well, we could unlock at the _beginning_ of ATIEnterVT, but here's what I would suggest... Don't do locking/unlocking in ATIModeSet, but do the locking in the three functions in aticonsole.c: ATILeaveVT() 1. DRILock, then call ATILeaveGraphics 2. ATIModeSave 3. ATIModeSet (ok, we've got the lock already) 4. ATILock, return from ATILeaveGraphics 5. return ATIEnterVT() 1. call ATIEnterGraphics 2. ATIUnlock 3. ATIModeCalculate 4. ATIModeSave 5. ATIModeSet (we still hold the DRILock), return 6. DRIUnlock, return ATISwitchMode() 1. ATIModeCalculate 2. DRILock 3. ATIModeSet 4. DRIUnlock, return Here you can still avoid locking until after the mode calculate. Also ATIModeSet is called by ATIClockPreInit, and I don't think DRI locking is necessary at that point (in fact, I think it happens before the DRI initialization?). Of course, this is my high-level view (I haven't followed all the code in the sequence in detail) and I could be missing something. I'm also not sure exactly _where_ the lockup happens and so I'm not sure how fine grained the locking can get. What do you think? --Leif -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 locking
OK, I actually looked at the definition of DRILock/DRIUnlock (programs/Xserver/GL/dri/dri.c), and it does reference counting, so locking twice might not be an issue, it just increments the reference count. What I haven't found yet is where the DRM_LOCK/DRM_UNLOCK macros used in DRILock/DRIUnlock are defined, and I'm not sure how contention is handled either. So I'm going to try and get a better idea of how the locking is actually implemented, and hopefully I know what I'm talking about next time. --Leif -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Re:[Dri-devel] CVS XFree and StarOffice 6.0
On Sun, 2001-10-28 at 01:46, Papadakos Panagiotis wrote: There are problems with Xfree-4.1.0 and after.I don't know what,but if you want tou use Openoffice-Staroffice 6.0 you will have to work with Xfree-4.0.3. I found that the problem is with libXrender. If this library is relocated SO starts up (although with a warning that it didn't find libXrender). What is strange is that until very recently, it worked alright, with XFree 4.1.0 and libXrender and all that. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS XFree and StarOffice 6.0
On Sun, Oct 28, 2001 at 02:46:50AM +0300, Papadakos Panagiotis wrote: There are problems with Xfree-4.1.0 and after.I don't know what,but if you want tou use Openoffice-Staroffice 6.0 you will have to work with Xfree-4.0.3. I'm running Open Office 638 on XFree 4.1 just fine. Without more information as to what's happening when you try to run Star Office I don't think we can help you. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS XFree and StarOffice 6.0
Though I do not have either OpenOffice or StarOffice running, (I tried OpenOffice, some problems) I do know that OpenOffice calls for libGL. I would guess that your problem is in /etc/ld.so.conf You might want to put /usr/X11R6/lib in front of /usr/X11R6-DRI/lib in that file. Good luck, Carl Busjahn Gérard Milmeister wrote: I recently compiled and installed a CVS DRI XFree, and it seems to have affected StarOffice 6.0b and OpenOffice. It doesn't start up anymore. Has anybody had similar problems? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS XFree and StarOffice 6.0
I try to run setup from openoffice 638C and all I get is the message: glibc version: 2.2.3 and then I get back to the shell.I am using the latest CVS from Xfree and I am using a G400 Dualheaded.Also many other people have the same problem,but nobody has explained why this is happening. On Sat, 27 Oct 2001, Daryll Strauss wrote: On Sun, Oct 28, 2001 at 02:46:50AM +0300, Papadakos Panagiotis wrote: There are problems with Xfree-4.1.0 and after.I don't know what,but if you want tou use Openoffice-Staroffice 6.0 you will have to work with Xfree-4.0.3. I'm running Open Office 638 on XFree 4.1 just fine. Without more information as to what's happening when you try to run Star Office I don't think we can help you. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS XFree and StarOffice 6.0
On Sun, 2001-10-28 at 02:02, Daryll Strauss wrote: I'm running Open Office 638 on XFree 4.1 just fine. Without more information as to what's happening when you try to run Star Office I don't think we can help you. What do you need? An strace? -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re:[Dri-devel] CVS XFree and StarOffice 6.0
The StarOffice 6.0 beta works just fine here on X 4.1.0[.1, it's a Debian sid package, 4.1.0-9]. --- Dan Chen [EMAIL PROTECTED] GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc On Sun, 28 Oct 2001, Papadakos Panagiotis wrote: There are problems with Xfree-4.1.0 and after.I don't know what,but if you want tou use Openoffice-Staroffice 6.0 you will have to work with Xfree-4.0.3. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
