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*.
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.)
-- Garrett
>
> -- Eric
>
>
> Garrett D'Amore wrote:
>> Eric Sultan wrote:
>>> The intended delivery target for rfb is OpenSolaris. The
>>> OpenSolaris system will not support Xsun, and hence will not have
>>> the Xsun-compatible pfb and nfb software components. There should
>>> not be a conflict, then, between pfb/nfb and rfb.
>>>
>>> Alan asked about whether the pfb/nfb kernel device drivers could be
>>> modified to work with the Xorg ddx module. In theory, they could,
>>> but it would produce a rather chimerical product. The rfb product,
>>> for example, uses the DRI/DRM, and the pfb/nfb products do not.
>>>
>>> Since Xsun has been EOL'd and we're working towards an Xorg
>>> environment, the project chose to move forwards with an
>>> opensource-derived Xorg-compliant support for the XVRs 50, 100, and
>>> 300.
>>>
>>> Edward asked if rfb would support the Coherent Console system. Yes,
>>> that is the plan (and should be, since it's the SPARC graphics team
>>> that originally requested Coherent Console support).
>>
>> The only objection I have here is that the EOL of Xsun is not *just*
>> for OpenSolaris, but also for whatever Solaris release (11.x?) might
>> follow S10. I would really encourage the project team to consider a
>> solution where the driver names don't change, so that an upgrade from
>> S10 (or earlier) to this driver could be done "painlessly".
>>
>> Having different device driver names for S10 and OpenSolaris is only
>> likely to increase pain elsewhere in the future. (And yes, this is a
>> Sun-only concern, not really related to OpenSolaris, but it is worth
>> resolving nonetheless.)
>>
>> Its also possible that at some time in the future, "upgrades" between
>> Solaris (Sun) and OpenSolaris might be desired. While there are
>> numerous technical hurdles to solve for such, I would prefer to avoid
>> putting in *new* hurdles if I could help it.
>>
>> -- Garrett
>>>
>>> -- Eric
>>>
>>>
>>>
>>> Garrett D'Amore wrote:
>>>> Alan Coopersmith wrote:
>>>>> Eric Sultan wrote:
>>>>>
>>>>>> I'd need to consult with someone that knows release engineering
>>>>>> better
>>>>>> than I, but I'd think that the rfb driver should be made mutually
>>>>>> exclusive of the nfb and pfb drivers. I'm not familiar enough with
>>>>>> packaging and installation issues to know how to achieve this.
>>>>>>
>>>>>
>>>>> I don't think there is a way to do this other than choose one to not
>>>>> include with Solaris.
>>>>>
>>>>
>>>> Yes. And it creates nightmares on upgrade. If at all possible, I
>>>> *highly* recommend renaming the driver to the legacy names, so it
>>>> appears as a "drop in" replacement.
>>>>
>>>>>
>>>>>> Both drivers can exist in the system without competing with each
>>>>>> other. The first one found in the /etc/driver_aliases file is the
>>>>>> one that
>>>>>> would be used, but this doesn't seem to provide a useful
>>>>>> mechanism for
>>>>>> binding the driver to the device.
>>>>>>
>>>>>
>>>>> So how would users choose which to run? Why does a different
>>>>> kernel driver
>>>>> even need to be provided - can't the Xorg ddx module work with the
>>>>> old ones?
>>>>>
>>>>
>>>> Good point -- I look forward to Eric's reply.
>>>>
>>>> As an aside, I'm disappointed about the open source, but hopefully
>>>> we'll at least get binary redistribution rights? I'm also not sure
>>>> what the etiquette of submitting an open ARC case for a closed
>>>> source bit of software is.
>>>>
>>>> -- Garrett
>>>>
>>>
>>
>
