Re: [ddccontrol-devel] [RFC] A common platform usb/ddc/anything else ?

[L. <fr...@st...>]

Le vendredi 03 mars 2006 =C3=A0 21:26 +0100, Nicolas Boichat a =C3=A9crit=
 :
> Hi Fr=C3=A9d=C3=A9ric,
>=20
> On Tue, 2006-02-28 at 22:12 +0100, Fr=C3=A9d=C3=A9ric Leroy wrote:
> > Hello,
> >=20
> > I own an Apple Studio display without button to control it (which
> > integrates an usb hub) .
> > Long ago, I tried ddcci, without success. It was at alpha stage, with=
out
> > graphical user interface, but the monitor didn't seem to support ddc
> > interface.
>=20
> It would be nice if you could check quickly that it still doesn't
> work .-) Just in case... So we are sure we don't do useless work .-)
I read nowhere it is capable of that. But, meanwhile, I had new hardware
so I'll try again and keep you in touch.

> Nice, btw, do you know this document:
> http://www.usb.org/developers/devclass_docs/usbmon10.pdf . It could be
> useful.
I have this document thanks to your project :). I made some research on
usbmon, vcp, mccs ... but I didn't found anything interesting.=20
On vesa.org the standard can be buy for 350$+70$shipping IIRC ...
*ouch* !
Once the project is good enough to have audience, maybe we could set up
a paypal page to buy it and level up the vesa controls.

> As far as I know, controlling monitors using USB or DDC/CI is very
> similar (the only problem I see is caps string, but it's not a major
> issue). It also uses controls, and the protocols are very near, so we
> could keep the database, and most of the current program. So I think it
> is feasible to integrate USB support directly into ddccontrol, without
> having 2 sets of tools.
In usbmon, IIRC, it is written that vesa control page are made to standar=
dize controls, for any bus access.
There always be some minor difference in implementation, but basically,
as I understand usbmon, vcp are the same for ddc/ci, usb, whatever.
Then, It was obvious for me to contact you :)

> I already played a little with HID usb devices, but I don't remember
> very well the details. I don't know where you got so far, but here are
> some questions:
> Could you explain how do you interact with the monitor? Do you need a
> specific driver, or HID usb module is enough? Do you need a library
> (libusb? libhid?), or could you directly open a device (/dev/hiddev*
> devices?)? Is it possible for a non-root user to write to the device (b=
y
> setting the permissions to device?)?
Long ago, I tried first to use /dev/hiddev, without success.
Today, I just have some quick hacks in libhid and the test program to do
only one settings. So, basically, I have no code, but I know it is
working.

Since yesterday, I'am reading linux kernel litterature and kernel source
to make a kernel driver. After all, it's an hid device, and thus, must
have it own kernel driver.

I plan to do a kernel driver totally integrated with usb, hid device.
To use the control, I would use only sysfs, as I don't see how it can be
an input driver.

So, something like :
/sys/.../display/displayname/brightness_min # minimal value
/sys/.../display/displayname/brightness_max # maximal value
/sys/.../display/displayname/brightness     # setting=20
and maybe=20
/sys/.../display/displayname/unsupported_vcp/0xfe # meaning missing ...=20
/sys/.../display/displayname/vcp/0x10      # link to /sys/.../brigthness
to /sys/.../brigthness

Permission for controls are my big problem. I'm weak on this.
basically, the files above would have these permission, accorded to the
settings :=20
/sys/.../degauss     root:vcp   --w--w---
/sys/.../brightness  root:vcp   -rw-rw---
/sys/.../horizontal_frequency  root:vcp   -r--r----

> Needing a non-standard kernel module should be avoided, as it
> complicates installation (and packagers' work too). Using a standard
> kernel module like usbhid is ok.
I totally agree

> Needing a standard library like libusb is ok, libhid looks non-standard
> as far as I can tell (it is not even included in Gentoo), so avoid it i=
f
> you can.
libhid is very young and not very easy to deal with (I have to be root to=
 grab the usb device).
But, it's for me a nonsense to use libusb, as I will have=20
to borrow the parser of libhid ... so if I make a user interface, I will =
use and contribute to libhid.
The big advantage is to have it working on Linux, Mac osX, Bsd (put your
favorite os here) ...

> I would be happy to help you add support for USB devices. When you have
> working code, it would be nice if you could send to the list some
> example programs (get monitor ID (or the complete EDID), read or write
> from a control, enumerate supported controls (all these are essential
> features), and everything else you found out that you think is
> interesting), and some example output.
I'll need your help also. I have only one monitor to test.
I would be happy if user who own an usb monitor, sends me the hid report =
descriptor.
lsusb -vvv don't work because the monitor is grabbed by linux hid layer, =
it needs to unload=20
usbhid driver first I guess :( If someone has an easy solution to get
the report, tell me !
Or I can make a quick and dirty prog to do this.

> Then we will discuss how to integrate it in ddccontrol, and I'll give
> you a CVS access so you can work more freely.
I post to this list because I believe these two project are linked. I
prefer to discuss first and code after :) At least, warn you that I'll
maybe come back with something to integrate.
I code quite slowly, so it will take some time before I come back with
an alpha version of the kernel driver. In any case, I'will post my work
on this list. And once it's mature enough, on kernel usb mailing list
(unless I use only libhid).

> Thanks for your interest in this project,
It's natural ...

> Meilleures salutations,
Les formules de politesses ne sont pas mon fort, mais le coeur y est !
I hope your project to be successful.

Fr=C3=A9d=C3=A9ric