OK.  My personal preference is for a more descriptive name (at least 
when the name isn't something that has to be typed -- shortness trumps 
when names get typed often, as in NIC driver names), but it doesn't 
really matter that much.

    -- Garrett

Eric Sultan wrote:
> No, as with other graphics devices there is no particular mnemonic 
> significance to the name.  A longer, more descriptive, name could have 
> been chosen, though shorter names are more friendly when you have to 
> type them.
>
> efb was selected because:
>
>  - It doesn't collide with anything we could find
>  - It follows our general protocol of naming framebuffers as 
> <something>fb
>  - It's the first suitable letter in the alphabet that follows the .fb 
> format
>
> We tried to consider longer names that might have more descriptive 
> significance but hadn't found one that resonated, and we expect that 
> users will at times reference the device by this name and so, other 
> things being equal, shorter is better.
>
> Any rumor that efb is "eric's framebuffer" is just that: rumor.
>
>  -- Eric
>
> Garrett D'Amore wrote:
>> Eric Sultan wrote:
>>> It has been pointed out that VNC uses a remote framebuffer protocol 
>>> named "rfb", and that the name might therefore not be a good choice 
>>> for the Xorg-compliant driver for the XVR-50, -100, and -300.
>>>
>>> Accordingly, the project team has agreed to use a new name, efb, for 
>>> this project.
>>
>> Just out of curiosity, is there any mnemonic for efb?  And, is there 
>> any compelling reason why only three characters are chosen for the 
>> name?  (I would have expected that in new-style Xorg that users have 
>> little, if any, reason to be exposed to the names of the framebuffer 
>> drivers.... hence a longer and more descriptive -- and perhaps less 
>> likely to collide -- name seems like it might have been a good choice.)
>>
>> (No, I'm not asking the project to change their name, just pointing 
>> out that if they wanted to pick a longer and more descriptive name, 
>> that I think they *could* have.)
>>
>>    -- Garrett
>>
>


Reply via email to