On Fri, Jan 16, 2026 at 09:50:51AM -0300, Julio Faracco wrote: > Em sex., 16 de jan. de 2026 às 02:33, Peter Krempa > <[email protected]> escreveu: > > > > On Thu, Jan 15, 2026 at 23:52:29 -0300, Julio Faracco wrote: > > > This commit introduces the VIR_DOMAIN_INPUT_TYPE_MULTITOUCH enum value to > > > the virDomainInputType enumeration, laying the groundwork for multitouch > > > input device support in libvirt. > > > > > > The new enum value is added to src/conf/domain_conf.h following the > > > existing input types (mouse, tablet, keyboard, passthrough, evdev). This > > > establishes the fundamental type definition that will be used throughout > > > the codebase to identify and handle multitouch input devices. > > > > > > This is the first step in implementing support for QEMU's > > > virtio-multitouch > > > device, which was introduced in QEMU 8.1.0 and enables emulation of > > > multitouch events via the libvirt API. > > > > > > Signed-off-by: Julio Faracco <[email protected]> > > > --- > > > src/conf/domain_conf.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h > > > index cb35ff06bd..4c448bd010 100644 > > > --- a/src/conf/domain_conf.h > > > +++ b/src/conf/domain_conf.h > > > @@ -1554,6 +1554,7 @@ typedef enum { > > > VIR_DOMAIN_INPUT_TYPE_KBD, > > > VIR_DOMAIN_INPUT_TYPE_PASSTHROUGH, > > > VIR_DOMAIN_INPUT_TYPE_EVDEV, > > > + VIR_DOMAIN_INPUT_TYPE_MULTITOUCH, > > > > We require that the build passes cleanly after each patch. This > > obviously won't work with this since you fix up enums later. See > > contributor guildelines: > > > > https://www.libvirt.org/hacking.html#preparing-patches > > > > "If you're going to submit multiple patches, the automated tests must pass > > after each patch, not just after the last one." > > Oh, I missed that. Thanks for remembering me. It's been a long time > since my last contribution. > > > > > Multiple of your commit messages and especially 7/8 also have a strong > > LLM vibe. Note that we don't allow AI contributions: > > > > https://www.libvirt.org/hacking.html#use-of-ai-content-generators > > > > "Current libvirt project policy is to DECLINE any contributions which > > are believed to include or derive from AI generated content. This > > includes ChatGPT, Claude, Copilot, Llama and similar tools." > > > > > > Specifically paragraph: > > > > "These additions ensure that multitouch devices are fully integrated > > with libvirt's security, auditing, and validation infrastructure. > > Without these changes, multitouch devices would trigger warnings about > > unhandled enum values or potentially cause security labeling failures. > > > > strikes as AI. Because it's overly verbose and half of the things that > > are mentioned are not even true (e.g. it adds no-op code to the selinux > > driver), the other half is trying to justify fix for build failures from > > previous patches. > > > > I DO NOT use AI agents to generate code obviously, but I do to improve > the quality of the commit message/cover letter. > Let me resend the patch to fix the compilation issues and use my own words > then.
Using an AI agent to improve commit messages *is* permitted under policy. Whether written by a human or LLM, the overriding expectation is that the commit messages are providing an appropriate level of detail for the type of change being made and that they are accurate of course. Given AI agents tendancy to be ridiculously verbose LLM generated commit messages are quite likely to need significant editting to reduce verbosity, aside from vetting that it is accurate. IMHO that suggests LLMs are not especially beneficial for writing commit messages, but contributors can make that decision for themselves, as long as the result is accurate & appropriately verbose for the change. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
