1. Patchew
  2. Libvirt
  3. [PATCH 0/8] Add multitouch input device support
  4. View patch

[PATCH 1/8] conf: Add multitouch input type enum

Julio Faracco posted 8 patches 2 weeks, 3 days ago
There is a newer version of this series
[PATCH 1/8] conf: Add multitouch input type enum
Posted by Julio Faracco 2 weeks, 3 days ago 
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 <jcfaracco@gmail.com>
---
 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,
 
     VIR_DOMAIN_INPUT_TYPE_LAST
 } virDomainInputType;
-- 
2.52.0
Re: [PATCH 1/8] conf: Add multitouch input type enum
Posted by Peter Krempa via Devel 2 weeks, 3 days ago 
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 <jcfaracco@gmail.com>
> ---
>  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."

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.
Re: [PATCH 1/8] conf: Add multitouch input type enum
Posted by Julio Faracco 2 weeks, 2 days ago 
Em sex., 16 de jan. de 2026 às 02:33, Peter Krempa
<pkrempa@redhat.com> 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 <jcfaracco@gmail.com>
> > ---
> >  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.

Thanks, Peter
Re: [PATCH 1/8] conf: Add multitouch input type enum
Posted by Daniel P. Berrangé via Devel 2 weeks, 2 days ago 
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
> <pkrempa@redhat.com> 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 <jcfaracco@gmail.com>
> > > ---
> > >  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 :|
Re: [PATCH 1/8] conf: Add multitouch input type enum
Posted by Julio Faracco 2 weeks, 2 days ago 
Em sex., 16 de jan. de 2026 às 10:06, Daniel P. Berrangé
<berrange@redhat.com> escreveu:
>
> 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
> > <pkrempa@redhat.com> 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 <jcfaracco@gmail.com>
> > > > ---
> > > >  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.

What I have tried to say is exactly that: before sending the patches I
just ask LLMs to review the commit messages of my patches and make
improvements.
But yes, it tends to increase the verbosity significantly.

Well, I understood the feedback. Let me fix the patchset and resubmit
using my own words only.
(Perhaps one good adjustment is just using LLMs to fix orthography and typos)

>
> 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 :|
>

Thanks!

--
Julio Faracco
Re: [PATCH 1/8] conf: Add multitouch input type enum
Posted by Peter Krempa via Devel 2 weeks, 2 days ago 
On Fri, Jan 16, 2026 at 09:50:51 -0300, Julio Faracco wrote:
> Em sex., 16 de jan. de 2026 às 02:33, Peter Krempa
> <pkrempa@redhat.com> escreveu:

[...]

> > 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.

What you did definitely *DID NOT* improve the quality. It did the exact
oposite!

Commit messages are part of the contribution, and putting AI slop there
(and what you've sent is slop because it's overly verbose, misleading
and with basically 0 value) is actively bad for the project. When I read
a commit message I do that so that I gain understanding why something
happened or understand some detail which may not be obvious from the
code.

Putting 3 paragraphs of basically useless garbage description for a 1
line change wastes time and shows total disrespect to anyone who'd want
to understand what's going on. That's especially the case for the
wrong/misleading description of the addition to the security driver and
possibly others.

Commit messages don't need to be novels/pages full of text, but rather
need to contain detail not present in the code. And also make sure to
consider that people *do* read them, they are not just for decoration.

> Let me resend the patch to fix the compilation issues and use my own words then.

If you didn't use AI to generate the code then just get rid of all the
slop from the commit messages.

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.