From: Thierry Reding <thierry.reding@gmail.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH libdrm 2/3] xf86drm: Add USB support
Date: Mon, 2 Jan 2017 14:26:26 +0100 [thread overview]
Message-ID: <20170102132626.GA7587@ulmo.ba.sec> (raw)
In-Reply-To: <CACvgo52hQHBgUz18vQY0yg4OC1jboUhONgFU3WwEqf+9tgddTg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2625 bytes --]
On Sat, Dec 24, 2016 at 04:38:04PM +0000, Emil Velikov wrote:
> Hi Thierry,
>
> On 23 December 2016 at 17:49, Thierry Reding <thierry.reding@gmail.com> wrote:
> > Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
> > infrastructure.
> >
> > Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
> > ---
> > Note that this is completely untested because I don't have a UDL device
> > for testing. I'm fairly confident that this will work, though, and it'd
> > be nice to include it before the new platform and host1x busses because
> > support for it existed in the kernel longer than for platform devices.
> >
> Functionality looks spot on, but I'm a bit hesitant to get this in
> without any testing.
> Can we please extend tests/drmdevice.c (separate patch?) as poke
> someone on dri-devel/xorg-devel to give it a quick run ?
I can do that.
> > +static int drmParseUsbDeviceInfo(int maj, int min, drmUsbDeviceInfoPtr info)
> > +{
> > + char path[PATH_MAX + 1], *value;
> > + unsigned int vendor, product;
> > + int ret;
> > +
> > + snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
> > +
> > + value = sysfs_uevent_get(path, "PRODUCT");
> > + ret = sscanf(value, "%x/%x", &vendor, &product);
> > + free(value);
> > +
> > + if (ret <= 0)
> > + return -errno;
> > +
> > + info->vendor = vendor;
> > + info->product = product;
> > +
> Worth fetching bcdDevice as well ?
This is currently only parsing the uevent file, which doesn't have
bcdDevice. The only data that isn't currently being parsed is TYPE
(bDeviceClass/bdeviceSubClass/bDeviceProtocol), not sure if we'd
want that.
I could of course read bcdDevice from the bcdDevice file.
One thing that I realized the other day, and it's relevant to all of
drmDevice, not just USB, is that we don't have a good way of preserving
ABI compatibility. With the USB and platform/host1x bus patches we're
not running into problems yet, but consider what would happen if we
added more bus or device info. The drmDevice.businfo and
drmDevice.deviceinfo unions could be growing beyond what they are now,
causing applications written against old versions to potentially
allocate too little memory.
I wonder if that's something we need to care about. As long as we keep
the bus and device info fixed after they've been added, we should be
safe because the bus type will be unknown to earlier versions and hence
cause the code to error out early. Technically we wouldn't be able to
ever extend one type of bus or device info, though.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-01-02 13:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-23 17:49 [PATCH libdrm 0/3] xf86drm: Add USB, platform and host1x bus support Thierry Reding
2016-12-23 17:49 ` [PATCH libdrm 1/3] xf86drm: Factor out drmDeviceAlloc() Thierry Reding
2016-12-23 17:49 ` [PATCH libdrm 2/3] xf86drm: Add USB support Thierry Reding
2016-12-24 16:38 ` Emil Velikov
2017-01-02 13:26 ` Thierry Reding [this message]
2017-01-04 14:02 ` Emil Velikov
2016-12-23 17:49 ` [PATCH libdrm 3/3] xf86drm: Add platform and host1x bus support Thierry Reding
2016-12-24 17:00 ` Emil Velikov
2017-01-02 13:53 ` Thierry Reding
2017-01-09 16:54 ` Emil Velikov
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=20170102132626.GA7587@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
/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.