Re: [Xen-devel] Re: More virtio users
Hi, Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Rectangles work just fine for a framebuffer console. They stop working once you plan to run any graphical stuff such as an X-Server on top of the framebuffer. Only way to get notified about changes is page faults, i.e. 4k granularity on the linear framebuffer memory. Related to Framebuffer is virtual keyboard and virtual mouse (or better touchscreen), which probably works perfectly fine with virtio. I'd guess you can even reuse the input layer event struct for the virtio events. Xen has virtual framebuffer, kbd mouse, although not (yet?) in the paravirt_ops patch queue, so there is something you can look at ;) cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Re: More virtio users
Gerd Hoffmann wrote: Hi, Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Rectangles work just fine for a framebuffer console. They stop working once you plan to run any graphical stuff such as an X-Server on top of the framebuffer. Only way to get notified about changes is page faults, i.e. 4k granularity on the linear framebuffer memory. Related to Framebuffer is virtual keyboard and virtual mouse (or better touchscreen), which probably works perfectly fine with virtio. I'd guess you can even reuse the input layer event struct for the virtio events. Virtio seems like overkill for either of those things. It's necessary for pure PV but not at all necessary for something like KVM. Xen has virtual framebuffer, kbd mouse, although not (yet?) in the paravirt_ops patch queue, so there is something you can look at ;) In retrospect, IMHO, a shared framebuffer was a bad idea for Xen. It's easy enough for dealing with an unaccelerated display, but once you start getting into more advanced features like blitting (which is really important actually for decent VNC performance), the synchronization becomes a big problem. If we were to do a PV display driver again, I really think something that is closer to a VNC protocol is the right way to go. There simply isn't a significant performance overhead to copying the relatively small amount of memory. So virtio in it's current form would actually be pretty useful for that. Regards, Anthony Liguori cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Re: More virtio users
On Mon, 2007-06-11 at 10:16 +0200, Gerd Hoffmann wrote: Hi, Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Rectangles work just fine for a framebuffer console. They stop working once you plan to run any graphical stuff such as an X-Server on top of the framebuffer. Only way to get notified about changes is page faults, i.e. 4k granularity on the linear framebuffer memory. Yes, I discussed this with Ben Herrenschmidt a couple of months ago. It would be better to provide a fb ioctl which X could use to describe changed rectangles if available. In the virtio case we could hand that information through, and other virtualized framebuffers would be able to use it similarly. Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Re: More virtio users
Rusty Russell wrote: On Mon, 2007-06-11 at 10:16 +0200, Gerd Hoffmann wrote: Hi, Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Rectangles work just fine for a framebuffer console. They stop working once you plan to run any graphical stuff such as an X-Server on top of the framebuffer. Only way to get notified about changes is page faults, i.e. 4k granularity on the linear framebuffer memory. Yes, I discussed this with Ben Herrenschmidt a couple of months ago. It would be better to provide a fb ioctl which X could use to describe changed rectangles if available. In the virtio case we could hand that information through, and other virtualized framebuffers would be able to use it similarly. The X fbdev driver is going to make supporting a new fb ioctl pretty fun. It currently doesn't even support the existing fb ioctls and has a strange abstraction layer. I reckon writing a new X driver from scratch (or based on something like the vnc X driver) would be easier in the long run. Regards, Anthony Liguori Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Re: More virtio users
The X fbdev driver is going to make supporting a new fb ioctl pretty fun. It currently doesn't even support the existing fb ioctls and has a strange abstraction layer. I reckon writing a new X driver from scratch (or based on something like the vnc X driver) would be easier in the long run. Hrm... adding something to X fbdev should be fairly trivial... in fact, it already have some sort of ShadowFB support which we could use to track damage though it's less nice than using the damage extension I've been told. Ben. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
