GSoC Idea: Adding support for DMX screens to dix

[Cody Maloney]

I Just want to say I won't be able to apply for GSoC this summer as
other things have come up. I'll probably work on the X video driver
which renders to an X screen though in any spare time I have over the
summer. If someone else wants to feel free to use any of my ideas for
your own GSoC application, or work on any independently. These are
some features I'd really like to see make it into X. They would
eliminate a lot of redundant code and add some cool new functionality.

Thanks,
Cody Maloney

On Tue, Mar 30, 2010 at 3:41 PM, Cody Maloney
<cmaloney at theoreticalchaos.com> wrote:
> Thanks for your comments. I'll probably submit a proposal for both
> pieces you broke it into, although I'd lean towards the graphics
> hotplugging (specifically writing patches to add the necessary new
> hooks to the porting layer, as well as patches to implement the hooks
> in the xfree86 backend). If I end up with time left in the summer
> after implementing the hooks, then I'd work implementing the udev
> hooks.
>
> Thanks,
> Cody Maloney
>
> On Mon, Mar 29, 2010 at 12:32 PM, Jamey Sharp <jamey at minilop.net> wrote:
>> On Mon, Mar 29, 2010 at 12:10 PM, Cody Maloney
>> <cmaloney at theoreticalchaos.com> wrote:
>>> Currently the DMX X server works well enough to get display walls up
>>> and running. What I'd like to do is make it so that from a running X
>>> server you can dynamically add and remove DMX screens, without the
>>> need of the seperate DMX proxy server. This would be useful for
>>> instance to setup/use network screens/projectors. In addition, over it
>>> could move to replace the dmx X server which would mean that dmx would
>>> always be up to date with modern extensions. I'm not sure how feasible
>>> it is to add it to dix, and if there's a lot of work that needs to be
>>> done before it could happen (Removing MAXSCREENS?).
>>
>> Awesome. I've only glanced over what's needed for this, but it's
>> something I'd like to see happen.
>>
>> It seems to me that there are two substantial projects here, and I
>> think they're completely independent.
>>
>>
>>
>> I suspect either of those projects alone is easily big enough for
>> GSoC--possibly too big. A narrow focus is important.
>>
>> Jamey
>>
>