WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: USB with Xen2.0

> > On a related node, are you the brave chap who was trying to get a domain
> > to drive its own monitor?  How did that go?  Did Ian's suggestion (about
> > getting X to be less polite about virtual terminals) work?  It'd be
> > really interesting to get this going...
>
> Yeah, I'm still busy trying :-), I've managed to get a patched X version
> that doesn't require a true vt, but ran into some IO problem. I think I
> still need to do some more experiments.

Interesting...  Feel free to post back to this list if you're in need of 
assistance.  This is something we'd be really pleased to see working, 
particularly if the process can be simplified and streamlined for routine 
use.

I guess the X server might try doing IO to some things that Xen won't let it 
access.  By default, the domain will only have access to the IO ports and IO 
memory regions of the graphics card and USB controller themselves.

> It looks very promising, since I can do 'cat /dev/hda1 > /dev/fb0' and
> see the output on the display, I can do 'cat /dev/input/mouse0' and 'cat
> /dev/input/event0', and see the input of the mouse and keyboard, and
> with the patched xorg rpm I found, X should be able to use the event0
> device as input.

This sounds very promising!

> On another track, would it be possible to write a backend & frontend for
> framebuffer devices? That could be another way to get X running in other
> domains, in case my current path is a dead end (it would certainly be
> nice for people who own a dualhead card, and want to use the second head
> in a second domain).

Yes, it would be possible to do that for framebuffer devices.  The Nemesis 
operating system (also from Cambridge Computer Laboratory) did something 
similar to allow individual processes to do their own rendering.  I'm not 
sure this provides a huge advantage over existing remote-desktop protocols 
although the performance could be better.

A more difficult problem is that of virtualising 3D graphics hardware.  I 
think there's some ideas hanging around and it'd certainly be cool if domains 
could use the 3D hardware.  This is one of those "on the horizon" things at 
the moment, as far as Xen is concerned.

HTH,
Mark


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel