[PATCH] remove dead code in dummy driver

[Bob Terek]

On 09/23/2016 07:20 AM, Aaron Plattner wrote:

> On 09/22/2016 04:30 PM, Bob Terek wrote:

>> Shouldn't the first 5 of Aaron's patches be applied, since they are all
>> cleanup items?
>>
>>     https://lists.x.org/archives/xorg-devel/2015-January/045395.html
>
> I never pushed them because they were never reviewed. Would it help if I
> resent them?

Why don't you hold off for a bit. . .


>> Patch 6 supposedly caused a server crash, but the first 5 should be ok?
>
> Patch 6 was kind of controversial so I don't know if we want it anyway.

Welp, on that topic, your patch 6 was an alternative approach to support 
arbitrary pixel dimensions for the framebuffer. The more conventional 
approach had been posted by Boichat, 
https://lists.x.org/archives/xorg-devel/2014-November/044580.html . I'd 
like to suggest that Boichat's approach be used, but extended even further:

In 2014 I had also modified the dummy driver while working with Teradici 
Corporation to support not only arbitrary pixel dimensions, but also 
multiple monitors. The latter feature might not make sense to some 
folks, but if you have a server-side Xserver mapped to a hardware thin 
client sitting across a network, which has multiple physical monitors 
attached, you want the Xserver to be configured in the exact same manner 
as the tin client. Even though there is just a virtual framebuffer in 
main memory, X applications need to know the number/size/location of 
monitors so that toolbars are placed properly, windows are fullscreen'ed 
properly, etc. And when the user moves from one hardware thin client to 
another, which may have a different monitor configuration, the Xserver 
session needs to change to that configuration.

At Teradici we made dummy be RandR 1.2 compliant in a manner similar to 
Boichat, but added xorg.conf parameters to specify how many CRTC/Outputs 
should be created at startup. Thus the configuration could be 
manipulated via the standard RandR API (either programatically or 
through the xrandr command). This might happen when the hardware thin 
client connects to an existing X session, and server-side session 
management software will issue what is needed to reconfigure the 
Xserver. The end result is that the hardware thin client could be 
supported by multiple CRTC/Output's, with typical VESA modes, but a 
software thin client could use arbitrary pixel dimensions on a single 
CRTC/Output to map exactly the size of the window it was running in.

Teradici and I would like to submit these patches to dummy to support 
the functionality that many want. The dummy driver is so simple that I 
don't see this as overly complex. Yes, it is a bit more code to add, but 
it is very straightforward, nothing at all surprising. And it is 
backwards compatible, the multiple CRTC/Output support does not have to 
be utilized, the default is 1. Our modified driver behaves just like the 
current one, except that arbitrary modes may be added and switched to 
via the RandR protocol.

I can post these patches, and include Aaron's cleanups, if folks will 
support this approach. It has been tested via Teradici for over a year 
and seems to be stable. I am in the process of updating the code to the 
current version and so far so good.

Thoughts?

Thanks,

Bob Terek