On 9/11/23 15:12, Laszlo Ersek wrote: > On 9/11/23 10:53, Gerd Hoffmann wrote: >> On Mon, Sep 11, 2023 at 12:12:43PM +0400, Marc-André Lureau wrote: >>>> Gerd, here's the question for you: why are "device" and "head" QOM >>>> properties in the first place? What are they needed for? >>>> >>> >>> You get QOM tree introspection (ex: (qemu) qom-get >>> /backend/console[0]/device type). Other than that, I don't think it >>> brings anything else. >> >> You can configure vnc server(s) to show a specific device + head, which >> allows to run multihead configurations by using multiple vnc servers (one >> for each head). >> >> You can link input devices to device + head, so input events can go to >> different devices depending on where they are coming from. Which is >> most useful for tablet devices in a vnc multihead setup, each head has >> its own tablet device then. Requires manual guest-side configuration >> to establish the same tablet <-> head relationship (tested that years >> ago with X11, not sure if and how this can be done with wayland). > > OK, so I'm going to drop patch#3.
Hmmm, wait, I originally asked about the "QOM trickery" for a different reason. There are two things: - using (exposing) QOM properties for introspection, - using those propreties for internal access. Patch#3 would eliminate property use *internally*, it would not interfere with the use case explained by Gerd. I originally asked about QOM because I wanted to know where to *stop removing* QOM stuff. Like, once I replaced the QOM accessors with normal C struct / field accesses in qemu_console_is_multihead(), why would I stop there, and not just remove the "head" and and "device" properties altogether? With Gerd's explanation, I understand we need to keep those properties -- but that doesn't seem to imply we *must* use the properties even in internal functions such as qemu_console_is_multihead(). There, we can just go for direct field access; is that right? (IOW I'd still keep patch#3, if I can!) Thanks! Laszlo
