From: Matthew Jackson <matthew@pq.io>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [PATCH 2/2] hw/usb/dev-hid: add apple-mighty-mouse
Date: Mon, 20 Jul 2026 09:51:47 -0700 [thread overview]
Message-ID: <20260720095147.maydell-reply@pq.io> (raw)
In-Reply-To: <CAFEAcA9Mqtk65y9jJCWZgmRUMwgV+Sz7Y=R=Pp5R5huNj8cLjw@mail.gmail.com>
On Mon, 20 Jul 2026 at 08:22, Peter Maydell <peter.maydell@linaro.org> wrote:
> Reading this comment prompts me to check with you whether you have
> read our AI contribution policy, which at present is essentially
> a "no AI generated code or text in contributions" policy:
> https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-generated-content
Thanks Peter, and fair question -- the answer is yes, AI tooling was
used in producing this series, so under the current policy I should not
have sent it in this form. I apologise for that, and I appreciate you
flagging it directly rather than just dropping the patches.
To be transparent about what that means for these patches: this work
comes out of a project that runs macOS guests on QEMU/KVM, and I use an
AI coding assistant in that project. The comment you quoted is a good
example -- it's essentially the assistant's working notes shipped
verbatim, which is exactly the kind of thing that shouldn't be in an
upstream submission (and, as you say, the development-history narrative
doesn't belong there regardless of how it was written).
What is *not* AI-derived is the hardware ground truth: the USB
descriptors, HID report descriptors and endpoint topology are captured
byte-for-byte from real Apple peripherals, and the design decisions
(which device to emulate, why Mighty Mouse rather than Magic Trackpad,
how it binds in macOS) were mine. But I recognise that doesn't resolve
the DCO clause (b) concern about the generated code and text itself, and
I don't want to hand-wave that.
So I'll withdraw this series for now rather than ask you to review it
under a cloud. If I reimplement the device code and comments myself,
from the captured hardware descriptors as the spec, would a resubmission
be welcome -- or would you rather this category of contribution wait
until the AI policy itself is revisited?
Not looking to litigate the policy -- just want to be straight about
provenance and do the right thing here. Thanks again.
-- Matthew
next prev parent reply other threads:[~2026-07-20 16:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-19 15:23 [PATCH 0/2] hw/usb/dev-hid: Apple Magic Keyboard and Mighty Mouse emulators Matthew Jackson
2026-07-19 15:23 ` [PATCH 1/2] hw/usb/dev-hid: add apple-magic-keyboard Matthew Jackson
2026-07-19 15:23 ` [PATCH 2/2] hw/usb/dev-hid: add apple-mighty-mouse Matthew Jackson
2026-07-20 8:22 ` Peter Maydell
2026-07-20 16:51 ` Matthew Jackson [this message]
2026-07-20 18:24 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720095147.maydell-reply@pq.io \
--to=matthew@pq.io \
--cc=kraxel@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.