Thread: [XonX-Users] XFree86 compatibility plans
Brought to you by:
torrey
From: Torrey T. L. <to...@mr...> - 2001-10-27 03:45:44
|
This is one of those "speak now or forever hold your peace" opportunities... :-) The runtime compatibility issues with XFree86 in IOKit mode from the console between the Darwin 1.3 and Darwin 1.4 have turned out to be larger than I thought. There are several structures in the IOKit HID system that have incompatible changes and I haven't found any good and reasonably easy workarounds. (I can go into the issues off list if anyone is interested.) So, the current plan is to leave things as they are and build XFree86 4.2 on Mac OS X 10.1 for distribution. What this would mean is: 1. The XDarwin binary for the IOKit mode X server will only run on the same minor version of Darwin it was built on (Darwin 1.3 vs. 1.4). 2. The XFree86 Project will only distribute the binary for Darwin 1.4. The installer will warn users installing on Darwin 1.3 that the console X server will not work. (Of course others are free to build on Darwin 1.3 and distribute, but the likely user base is very small.) 3. Full screen and rootless Quartz modes will continue to work with either version of Mac OS X (10.0 or 10.1). 4. The usual two-level namespace caveats for backwards binary compatibility with 10.0.x apply. Ie. update_prebinding will crash after you've installed a two-level namespace binary including XFree86 4.2. See http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html. The current plan is also for XFree86 4.2 to be the last release with support for Mac OS X 10.0.4. There are several important features in Mac OS X 10.1 that we want to take advantage of that are broken in 10.0.4. Since these will involve significant changes to how we create and draw to rootless windows, there is no reasonable way to maintain backwards compatibility. --Torrey |
From: Don M. <ma...@ho...> - 2001-10-27 04:58:09
|
I'm afraid I have to give my input in the form of statements about how I use XFree86 and let you decide how they affects your decisions. I use XDarwin in rootless mode exclusively, but the only reason it's exclusive is so that I can use Apple's Command-Tab key-combo to switch between XDarwin and OS X (and Classic) applications. Otherwise I might very well be using rooted mode, as that would give me a broader choice of window managers (i.e., those that draw frames on the root window when windows are resized). It's highly unlikely that I will ever run Darwin without also running Aqua/OS X, so whatever interest I have in support for different versions of Darwin is driven entirely by which version of OS X I'm running. As Apple releases upgrades to OS X I plan to install them shortly after they're released. The X11 based application that I use the most, R (http://cran.r-project.org/) optionally sends graphics to an X11 window, and it had no problems with OS X 10.0.4 and XF86 4.1 alpha 3. Since I upgraded to 10.1, R's X11 driver will crash XDarwin under certain circumstances, reproducibly. So building XF86 4.2 on OS X 10.1 is a good thing (I'm hoping it will solve the problem). I don't really understand the difference between the IOKit mode X server and the Quartz mode X server. But I do know that I use Quartz mode, and I don't think I use IOKit mode, since I'm always running Aqua. So I don't believe that it matters to me which versions of Darwin IOKit mode runs on. Of course, maybe it does, and I just don't realize it. Thanks -Don At 8:45 PM -0700 10/26/01, Torrey T. Lyons wrote: >This is one of those "speak now or forever hold your peace" >opportunities... :-) The runtime compatibility issues with XFree86 >in IOKit mode from the console between the Darwin 1.3 and Darwin 1.4 >have turned out to be larger than I thought. There are several >structures in the IOKit HID system that have incompatible changes >and I haven't found any good and reasonably easy workarounds. (I can >go into the issues off list if anyone is interested.) So, the >current plan is to leave things as they are and build XFree86 4.2 on >Mac OS X 10.1 for distribution. What this would mean is: > >1. The XDarwin binary for the IOKit mode X server will only run on >the same minor version of Darwin it was built on (Darwin 1.3 vs. >1.4). > >2. The XFree86 Project will only distribute the binary for Darwin >1.4. The installer will warn users installing on Darwin 1.3 that the >console X server will not work. (Of course others are free to build >on Darwin 1.3 and distribute, but the likely user base is very >small.) > >3. Full screen and rootless Quartz modes will continue to work with >either version of Mac OS X (10.0 or 10.1). > >4. The usual two-level namespace caveats for backwards binary >compatibility with 10.0.x apply. Ie. update_prebinding will crash >after you've installed a two-level namespace binary including >XFree86 4.2. See >http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html. > >The current plan is also for XFree86 4.2 to be the last release with >support for Mac OS X 10.0.4. There are several important features in >Mac OS X 10.1 that we want to take advantage of that are broken in >10.0.4. Since these will involve significant changes to how we >create and draw to rootless windows, there is no reasonable way to >maintain backwards compatibility. > >--Torrey > >_______________________________________________ >XonX-Users mailing list >Xon...@li... >https://lists.sourceforge.net/lists/listinfo/xonx-users -- ------------------------- Don MacQueen ma...@ho... California, USA ------------------------- |
From: Justin T. <jtr...@ma...> - 2001-11-04 20:36:52
|
i'm really excited, i finally got x to work on my powerbook G4 running os 10.1! but now i'm confused, the last time i used xfree86 was an old version of RedHat, and it looked nothing like this, for one it had a little funny X-start button and such, do i just need a new window manager? |
From: Ron C. <rc...@ll...> - 2001-10-27 05:06:26
|
Torrey: very nice set of plans. I have one concern about dropping support for 10.0.4, which is that my experience so far is that XonX was very robust on 10.0.4 but quits frequently (approaching once per day) on 10.1. I can't say for sure whether this is a difference between 10.0.4 and 10.1, or between XDarwin 1.0a1 and 1.0a3, as I switched both at the same time, but I would bet on the Mac OS switch, and have half considered going back to 10.0.4. -Ron Cohen- Torrey T. Lyons writes: > This is one of those "speak now or forever hold your peace" > opportunities... :-) The runtime compatibility issues with XFree86 in > IOKit mode from the console between the Darwin 1.3 and Darwin 1.4 > have turned out to be larger than I thought. There are several > structures in the IOKit HID system that have incompatible changes and > I haven't found any good and reasonably easy workarounds. (I can go > into the issues off list if anyone is interested.) So, the current > plan is to leave things as they are and build XFree86 4.2 on Mac OS X > 10.1 for distribution. What this would mean is: > > 1. The XDarwin binary for the IOKit mode X server will only run on > the same minor version of Darwin it was built on (Darwin 1.3 vs. 1.4). > > 2. The XFree86 Project will only distribute the binary for Darwin > 1.4. The installer will warn users installing on Darwin 1.3 that the > console X server will not work. (Of course others are free to build > on Darwin 1.3 and distribute, but the likely user base is very small.) > > 3. Full screen and rootless Quartz modes will continue to work with > either version of Mac OS X (10.0 or 10.1). > > 4. The usual two-level namespace caveats for backwards binary > compatibility with 10.0.x apply. Ie. update_prebinding will crash > after you've installed a two-level namespace binary including XFree86 > 4.2. See > http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html. > > The current plan is also for XFree86 4.2 to be the last release with > support for Mac OS X 10.0.4. There are several important features in > Mac OS X 10.1 that we want to take advantage of that are broken in > 10.0.4. Since these will involve significant changes to how we create > and draw to rootless windows, there is no reasonable way to maintain > backwards compatibility. > > --Torrey > > _______________________________________________ > XonX-Users mailing list > Xon...@li... > https://lists.sourceforge.net/lists/listinfo/xonx-users > |
From: Christoph P. <cp...@ch...> - 2001-10-27 10:40:42
|
Torrey T. Lyons wrote: >This is one of those "speak now or forever hold your peace" >opportunities... :-) No objections from my side. Fink will start dropping explicit 10.0 compatibility once we're confident that everyone who's still waiting for their 10.1 update has received it. We simply don't have the resources to test all packages on both systems. That may be as soon as one or two weeks from now, but a new point release of Fink will probably be made before that. -chrisp -- chrisp a.k.a. Christoph Pfisterer "Any sufficiently advanced cp...@ch... - http://chrisp.de bug is indistinguishable PGP key & geek code available from a feature." |
From: Alan H. <al...@fa...> - 2001-10-27 11:48:48
|
On Fri, Oct 26, 2001 at 08:45:35PM -0700, Torrey T. Lyons wrote: > 2. The XFree86 Project will only distribute the binary for Darwin > 1.4. The installer will warn users installing on Darwin 1.3 that the > console X server will not work. (Of course others are free to build > on Darwin 1.3 and distribute, but the likely user base is very small.) > Torrey, Why can't we ifdef the build for two versions ? We do this on many platforms already. I'm willing to build the Darwin 1.3 release for you if need be and put that up on XFree86's site. And leave you to do 1.4. > The current plan is also for XFree86 4.2 to be the last release with > support for Mac OS X 10.0.4. There are several important features in > Mac OS X 10.1 that we want to take advantage of that are broken in > 10.0.4. Since these will involve significant changes to how we create > and draw to rootless windows, there is no reasonable way to maintain > backwards compatibility. > Like I say, I'd like to ifdef the build process if at all possible and I'm willing to make the effort to test and help here. The issues I see from my point of view is that 10.0.4 works on my PowerMac 8600 with the SonnetTech G4 450 board. Sonnet are supporting 10.1, but I'm worried that they may not support all versions in the future and thus leave me in an awkward position, if this issue arises again at some point. Thanks for listening. Alan. |
From: Torrey T. L. <to...@mr...> - 2001-10-27 20:31:49
|
At 12:48 PM +0100 10/27/01, Alan Hourihane wrote: >On Fri, Oct 26, 2001 at 08:45:35PM -0700, Torrey T. Lyons wrote: >> 2. The XFree86 Project will only distribute the binary for Darwin >> 1.4. The installer will warn users installing on Darwin 1.3 that the >> console X server will not work. (Of course others are free to build >> on Darwin 1.3 and distribute, but the likely user base is very small.) >> >Torrey, > >Why can't we ifdef the build for two versions ? > >We do this on many platforms already. I'm willing to build the Darwin >1.3 release for you if need be and put that up on XFree86's site. And >leave you to do 1.4. Actually, the source doesn't need any changes between Darwin 1.3 and 1.4. XDarwin just has to be built on the version of Darwin it will be run on. In the build process the appropriate definitions for the current OS version are picked up from the system header files. If you think it is important to distribute Darwin 1.3 compatible binaries, it would be easy enough to build for both and distribute them as, for example, Darwin-ppc-1.3 and Darwin-ppc-1.4 (and the new Darwin-ix86-1.4, which we should finally be ready for). We could instead make a single binary, but it would involve having both versions of the relevant header files available at build time. Besides being more work there would also be licensing issues if we included the various versions of the necessary APSL licensed header files in the XFree86 repository. > > The current plan is also for XFree86 4.2 to be the last release with >> support for Mac OS X 10.0.4. There are several important features in > > Mac OS X 10.1 that we want to take advantage of that are broken in >> 10.0.4. Since these will involve significant changes to how we create >> and draw to rootless windows, there is no reasonable way to maintain >> backwards compatibility. >> >Like I say, I'd like to ifdef the build process if at all possible and >I'm willing to make the effort to test and help here. This is certainly a possibility, although the changes will likely be quite substantial. After 4.2 comes out we can relook at the actual changes and the importance of maintaining compatibility back to 10.0. >The issues I see from my point of view is that 10.0.4 works on my >PowerMac 8600 with the SonnetTech G4 450 board. Sonnet are supporting >10.1, but I'm worried that they may not support all versions in the >future and thus leave me in an awkward position, if this issue arises >again at some point. This is something I hadn't considered. I certainly agree with you in principle that we should always try to maintain backwards compatibility. I would argue that 10.0.4 to 10.1 is a special case and that we would not need to do this again for the foreseeable future. However, we can certainly try and avoid breaking backwards compatibility even in this case if we have a developer, such as yourself, who is interested in preserving it. --Torrey -- |
From: Alan H. <al...@fa...> - 2001-10-27 22:23:50
|
On Sat, Oct 27, 2001 at 01:31:32PM -0700, Torrey T. Lyons wrote: > Actually, the source doesn't need any changes between Darwin 1.3 and > 1.4. XDarwin just has to be built on the version of Darwin it will be > run on. In the build process the appropriate definitions for the > current OS version are picked up from the system header files. If you > think it is important to distribute Darwin 1.3 compatible binaries, > it would be easy enough to build for both and distribute them as, for > example, Darwin-ppc-1.3 and Darwin-ppc-1.4 (and the new > Darwin-ix86-1.4, which we should finally be ready for). > > We could instead make a single binary, but it would involve having > both versions of the relevant header files available at build time. > Besides being more work there would also be licensing issues if we > included the various versions of the necessary APSL licensed header > files in the XFree86 repository. > Great. Then I'll build the Darwin-ppc-1.3 for you. I don't think it's an issue building explicitly for different platforms. We already to this for the likes of FreeBSD and create FreeBSD-2.x, 3.x and 4.x packages. > >Like I say, I'd like to ifdef the build process if at all possible and > >I'm willing to make the effort to test and help here. > > This is certainly a possibility, although the changes will likely be > quite substantial. After 4.2 comes out we can relook at the actual > changes and the importance of maintaining compatibility back to 10.0. > O.k. This is good, and again - I'm willing to help. > >The issues I see from my point of view is that 10.0.4 works on my > >PowerMac 8600 with the SonnetTech G4 450 board. Sonnet are supporting > >10.1, but I'm worried that they may not support all versions in the > >future and thus leave me in an awkward position, if this issue arises > >again at some point. > > This is something I hadn't considered. I certainly agree with you in > principle that we should always try to maintain backwards > compatibility. I would argue that 10.0.4 to 10.1 is a special case > and that we would not need to do this again for the foreseeable > future. However, we can certainly try and avoid breaking backwards > compatibility even in this case if we have a developer, such as > yourself, who is interested in preserving it. > If we create a couple of directories under the hw/darwin to maintain compatibility then I think that would help. Something like hw/darwin/os1.3, hw/darwin/os1.4. Kinda like the os-support directory under hw/xfree86. Then we can move the current source into the os1.3, and create new stuff in the os1.4 directory, and modify the hw/darwin Imakefile to depend on the current build machine. Alan. |