Garrett D'Amore wrote: > Eric Sultan wrote: >> I'm not sure I properly understand the dimensions of the problem. >> Wherever Xsun has been EOL'd and removed, there should not be any >> compatibility issues. When Xsun is removed, so must Xsun-only >> components such as nfb and pfb. Issues of coexistence could occur in >> systems that support both Xsun and Xorg, and so might want both >> nfb/pfb or rfb. If this is an issue, the driver binding can be >> unambiguously specified in the /etc/driver_aliases file. >> >> Using the rfb code as a drop-in replacement for the nfb/pfb code >> doesn't solve the problem. When one *wants* to run Xsun on a system >> that has both Xsun and Xorg support, one would need the old nfb or pfb >> drivers instead of the Xorg-compliant rfb driver. >> Renaming rfb as nfb and pfb wouldn't get the job done, would it? >> >> Am I missing something here? > > Yes, I think you are. > > What I'm talking about is an upgrade of Solaris 10 (or earlier!) to > Solaris Nevada (or later). To be quite honest, I doubt many people care > whether Xsun or Xorg is running on their system, provided that they have > *X11* for their *hardware*.
There is no such upgrade path at the moment (S10 or SX:CE to OpenSolaris IPS based system) so lets not assume that *if* one is developed it can't be taught to deal with this problem of switching from Xsun (and its associated kernel drivers) to Xorg. At this time we don't even know if the hardware that the new rfb driver will be supported on these future releases because we don't know when they are. If you are running S10 or SPARC today or SX:CE on SPARC and upgrade to an SX:CE release then the default is still Xsun and the older pfb/nfb drivers will still be in your driver_aliases. If someone wishes to manually switch to Xorg/rfb on SX:CE then that is a concious choice and will require manual intervention - documentation of how to do that would be an excellent thing for this case to provide. If you install the yet to be released OpenSolaris on SPARC the you won't have Xsun and never will have had it or pfb/nfb you only have Xorg and this rfb delivered by this case. You are really solving a problem that doesn't exist, lets not give the project team more work to do. > That's why I'm proposing that you treat rfb as a drop in. It doesn't > have to drop in to Xsun, but it should drop in from a user-experience > perspective. (Modulo some known differences, such as lack of Display > PostScript.) I think in this case it is a bad idea. This isn't like the problems seen in networking drivers. By requiring rfb to be a dropin replacement for pfb/nfb you means more work for the project team to solve a problem that I really don't think exists. I believe we will have better architecture by not forcing rfb to be a drop in replacement for the old Xsun based architecture. For comparison the equivalent thing was not required of x86 when it made the switch from Xsun to Xorg. -- Darren J Moffat
