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
>>
>
