Menu
▾
▴
ddccontrol-devel
|
From: L. <fr...@st...> - 2006-02-28 21:12:19
|
Hello, 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, without graphical user interface, but the monitor didn't seem to support ddc interface. The Apple display can be configured by usb. Recently, I hacked libhid, go coding, and was able to change the position of the screen :) Now, I will code a usefull tool for these VESA usb controls(libhid and/or kernel module, cli ?). As it have the same purpose as ddc/ci, It would be great to share common stuff. I was thinking about a common library and/or command line interface for ddc/usb in order to use the same gui/cli. Only one set of tool to command each kind of monitor. Do you think we can do that ? I'am at early stage, so I am open to all suggestion. regards,=20 --=20 Fr=C3=A9d=C3=A9ric Leroy <fr...@st...> |
|
From: Nicolas B. <ni...@bo...> - 2006-03-03 20:26:23
|
Hi Frédéric, On Tue, 2006-02-28 at 22:12 +0100, Frédéric Leroy wrote: > Hello, > > 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, without > graphical user interface, but the monitor didn't seem to support ddc > interface. 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 .-) > The Apple display can be configured by usb. > Recently, I hacked libhid, go coding, and was able to change the > position of the screen :) > Now, I will code a usefull tool for these VESA usb controls(libhid > and/or kernel module, cli ?). Nice, btw, do you know this document: http://www.usb.org/developers/devclass_docs/usbmon10.pdf . It could be useful. > As it have the same purpose as ddc/ci, It would be great to share common > stuff. > I was thinking about a common library and/or command line interface for > ddc/usb in order to use the same gui/cli. Only one set of tool to > command each kind of monitor. > > Do you think we can do that ? I'am at early stage, so I am open to all > suggestion. 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. 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 (by setting the permissions to device?)? 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. 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 if you can. 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. Then we will discuss how to integrate it in ddccontrol, and I'll give you a CVS access so you can work more freely. Thanks for your interest in this project, Meilleures salutations, Nicolas |
|
From: L. <fr...@st...> - 2006-03-03 22:46:21
|
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 |
|
From: Nicolas B. <ni...@bo...> - 2006-03-04 14:39:07
|
Hi, I just got in the ddccontrol-devel mail archive, and I found this project, which is rather inactive: http://acdcontrol.sourceforge.net/ It use /dev/hiddev* devices to control Apple displays. I said, long time ago, that I would work on merging their code into ddccontrol, finally it sounds like I forgot to do so, that's something I could work on in the near future, if you are ready to give me some help. Best regards, Nicolas |
|
From: Oleg I. V. <ol...@cs...> - 2006-03-06 10:17:00
|
Hi,
Fr=C3=A9d=C3=A9ric, we should avoid writing kernel modules. The reaso=
n is that=20
this would complicate ddccontrol installation.
Have you considered using libusb to access USB devices? This library =
is=20
specially designed to access usb devices from the userspace. Check this=20
link: http://libusb.sourceforge.net/ This library is currently ported to=20
several platforms, including MacOS X.
Nicolas: as for ddccontrol integration. Perhaps, it's good idea to=20
create something like a ddcusb application which should provide interface=
s=20
similar to ddcpci and add usb: namespace to the ddccontrol.
Regards,
Oleg.
----- Original Message -----=20
From: "Fr=C3=A9d=C3=A9ric Leroy" <fr...@st...>
To: "Nicolas Boichat" <ni...@bo...>
Cc: <ddc...@li...>
Sent: Saturday, March 04, 2006 1:46 AM
Subject: Re: [ddccontrol-devel] [RFC] A common platform usb/ddc/anythinge=
lse=20
?
> Le vendredi 03 mars 2006 =C3=A0 21:26 +0100, Nicolas Boichat a =C3=A9cr=
it :
>> Hi Fr=C3=A9d=C3=A9ric,
>>
>> On Tue, 2006-02-28 at 22:12 +0100, Fr=C3=A9d=C3=A9ric Leroy wrote:
>> > Hello,
>> >
>> > 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,=20
>> > without
>> > graphical user interface, but the monitor didn't seem to support ddc
>> > interface.
>>
>> 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 hardwar=
e
> 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.
> 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 i=
t
>> 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=20
> standardize 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 (=
by
>> 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 d=
o
> 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 sourc=
e
> 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 b=
e
> 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
> and maybe
> /sys/.../display/displayname/unsupported_vcp/0xfe # meaning missing ...
> /sys/.../display/displayname/vcp/0x10 # link to /sys/.../brigthnes=
s
> 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 :
> /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-standar=
d
>> as far as I can tell (it is not even included in Gentoo), so avoid it =
if
>> you can.
> libhid is very young and not very easy to deal with (I have to be root =
to=20
> grab the usb device).
> But, it's for me a nonsense to use libusb, as I will have
> to borrow the parser of libhid ... so if I make a user interface, I wil=
l=20
> use and contribute to libhid.
> The big advantage is to have it working on Linux, Mac osX, Bsd (put you=
r
> favorite os here) ...
>
>> I would be happy to help you add support for USB devices. When you hav=
e
>> 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 repor=
t=20
> descriptor.
> lsusb -vvv don't work because the monitor is grabbed by linux hid layer=
,=20
> it needs to unload
> 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
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting=20
> language
> that extends applications into web and mobile media. Attend the live=20
> webcast
> and join the prime developer group breaking into this new coding=20
> territory!
> http://sel.as-us.falkag.net/sel?cmd____________________________________=
___________
> ddccontrol-devel mailing list
> ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel=20
|
|
From: Nicolas B. <ni...@bo...> - 2006-03-06 12:31:20
|
Hi Oleg, Thanks for your message, Frédéric and I are in active discussion, off-list (and in French as it's easier for both of us .-)). As far as we know, there is three methods to access USB HID devices: - hiddev, really simple, just like i2c devices, but unfortunately it doesn't seem to work. - libhid over libusb, but it would require a kind of application like ddcpci, as it requires to be root (but it would work on many platforms, not only Linux). - a new kernel module, which of course is not the best solution. We are trying these methods one by one, starting with hiddev, and I hope we won't need to create a kernel module... Best regards, Nicolas On Mon, 2006-03-06 at 13:16 +0300, Oleg I. Vdovikin wrote: > Hi, > > Frédéric, we should avoid writing kernel modules. The reason is that > this would complicate ddccontrol installation. > > Have you considered using libusb to access USB devices? This library is > specially designed to access usb devices from the userspace. Check this > link: http://libusb.sourceforge.net/ This library is currently ported to > several platforms, including MacOS X. > > Nicolas: as for ddccontrol integration. Perhaps, it's good idea to > create something like a ddcusb application which should provide interfaces > similar to ddcpci and add usb: namespace to the ddccontrol. > > Regards, > Oleg. > > ----- Original Message ----- > From: "Frédéric Leroy" <fr...@st...> > To: "Nicolas Boichat" <ni...@bo...> > Cc: <ddc...@li...> > Sent: Saturday, March 04, 2006 1:46 AM > Subject: Re: [ddccontrol-devel] [RFC] A common platform usb/ddc/anythingelse > ? > > > > Le vendredi 03 mars 2006 à 21:26 +0100, Nicolas Boichat a écrit : > >> Hi Frédéric, > >> > >> On Tue, 2006-02-28 at 22:12 +0100, Frédéric Leroy wrote: > >> > Hello, > >> > > >> > 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, > >> > without > >> > graphical user interface, but the monitor didn't seem to support ddc > >> > interface. > >> > >> 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. > > 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 > > standardize 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 (by > >> 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 > > and maybe > > /sys/.../display/displayname/unsupported_vcp/0xfe # meaning missing ... > > /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 : > > /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 if > >> 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 > > 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 > > 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édéric > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > that extends applications into web and mobile media. Attend the live > > webcast > > and join the prime developer group breaking into this new coding > > territory! > > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > > ddccontrol-devel mailing list > > ddc...@li... > > https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel > > |
|
From: L. <fr...@st...> - 2006-03-13 00:20:06
|
Hello, I have very little time to work on it and will be off for 2-3 days more. Le lundi 06 mars 2006 =C3=A0 13:26 +0100, Nicolas Boichat a =C3=A9crit : > Hi Oleg, > As far as we know, there is three methods to access USB HID devices: > - hiddev, really simple, just like i2c devices, but unfortunately it > doesn't seem to work. I started to debug hiddev this evening. I found that hid-core is not reporting first bytes of the "hid report descriptor" in good order. I'll try on a i386 computer later and have good hope to make hiddev or the monitor work right. I don't know if it is kernel or display's fault. Even if it is a display bug, I think we should be able to add hiddev support in ddccontrol. > - libhid over libusb, but it would require a kind of application like > ddcpci, as it requires to be root (but it would work on many platforms, > not only Linux). I post a little patch on libhid to add vital function needed for "features hid report", but noone answered :( Without this I can't make usb command work on my monitor, so I let this away for the moment. > - a new kernel module, which of course is not the best solution. Still on air for me, just for fun. It could be the only solution for me if my monitor hid implementation is crawled by bugs :) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X