ddccontrol-devel — Development list.

Re: [ddccontrol-devel] Status of next release

[Roberto S. <ro...@fa...>]

Nicolas Boichat wrote:
>
> ddccontrol builds fine, without warning, with gcc-4.1.1 (gentoo).
> 

OK.  Just so that I am clear, are you referring to the CVS version?  If 
I recall correctly, the most recent release only builds clean with gcc 3.4.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

Re: [ddccontrol-devel] Question on man pages and Spanish translations

[Roberto S. <ro...@fa...>]

Hi Nicolas,

Nicolas Boichat wrote:
> Hi Roberto,
> 
> I should have answered sooner, I'm really busy (university...).
> 
I know how it is :-)

> Roberto C. Sanchez wrote:
>> Hello,
>>
>> First question:
>>
>> As part of packaging for Debian, every executable binary requires a
>> corresponding man page.  Is it OK if I just create a directory called
>> man under the ddccontrol modules in CVS and add the man pages there?
>>   
> Of course it's ok.

I will start on it as soon as I can.  I am currently wrapping up my 
master's research to collect data for my last publication.

>> What is the best way to set this up to make certain that translated man
>> pages can be added without cluttrering everything up?
>>   
> I don't know anything about man pages... Sorry. Set it up as you think
> it should, then we will correct it if we have problems with translations.
OK.

>> Second question:
>>
>> What is the status of translating the UI into Spanish?  I notice that
>> there are already a few translations, but Spanish is not one.  Has
>> someone committed to doing a Spanish translation?  If not, I can start
>> on them in about a month or so.
>>   
> No, some people wanted to do the job, but nothing came. Feel free to do
> the job .-)
> 
OK.  As soon as I get some time I will start on this as well.

> Thanks,
> 
> Best regards,
> 
> Nicolas
> 

Cheers,

Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

Re: [ddccontrol-devel] Question on man pages and Spanish translations

[Nicolas B. <ni...@bo...>]

Hi Roberto,

I should have answered sooner, I'm really busy (university...).

Roberto C. Sanchez wrote:
> Hello,
>
> First question:
>
> As part of packaging for Debian, every executable binary requires a
> corresponding man page.  Is it OK if I just create a directory called
> man under the ddccontrol modules in CVS and add the man pages there?
>   
Of course it's ok.
> What is the best way to set this up to make certain that translated man
> pages can be added without cluttrering everything up?
>   
I don't know anything about man pages... Sorry. Set it up as you think
it should, then we will correct it if we have problems with translations.
> Second question:
>
> What is the status of translating the UI into Spanish?  I notice that
> there are already a few translations, but Spanish is not one.  Has
> someone committed to doing a Spanish translation?  If not, I can start
> on them in about a month or so.
>   
No, some people wanted to do the job, but nothing came. Feel free to do
the job .-)

Thanks,

Best regards,

Nicolas

Re: [ddccontrol-devel] [ddccontrol-users] Could the xml files be auto-generated?

[Nicolas B. <ni...@bo...>]

Hi,

David R Mulligan wrote:
> I was wondering if these files could be auto-generated, tweaked and then
> submitted.  It seems that the output of the ddccontrol util is taken at
> face value for the first version so why can't it be used to generate a
> test xml file?  Perhaps it could be done with some interaction from the
> user?
That's something I thought about, but unfortunately I think it is too
complicated to do. xml files are not very complicated to create, but it
needs some intelligence and experience about how DDC/CI works (or
doesn't work), which a computer program cannot provide. For example,
these are things I've done to create the database:
- Google, ask if the monitor is a LCD or a CRT (so I don't define absurd
controls like "pincushion" for LCDs)
- see that there is a missing parenthesis in monitor caps (Philips)
- see that a monitor reports strange values for some controls, so ask
the user if the controls really works (like the Samsung 215tw)
- create CAPS manually for an old monitor only supporting DDC/CI
partially (Samsung 173s)
- see that some controls are useful, but not in CAPS (very common for
Samsung)
- ask NEC-Mitsubishi / Fujistu-Siemens about the missing controls (I
have contact with these two manufacturer)
- etc...

xml-file creation has also been really simplified with the introduction
of generic profiles, it is also less important to have full support for
monitor as the user, without having a specific file for his monitor,
already has basic support (like brightness, which is probably the most
wanted control .-)).
> Part of why I am asking is the because of the mistakes made in some of
> the recent xml files
What mistakes ? Please tell me and I would be happy to fix these.
> as well as the fact that I am sure Nicolas would
> like some of his time back to do more interesting things than to parse
> the monitor capability output text to generate xml definition files :)
>   
Of course I would like to do something else, but unfortunately, nothing
is simple with the monitors: controls are far from standard, and even
for a specific manufacturer, the same control sometimes behaves
differently (look at SAMlcd.xml for example), and a lot of monitors are
buggy.

If I had time, I would like to do some work on gddccontrol (add more
full screen patterns for example), add support for read-only controls in
the database (to support rotation for example), allow better integration
with scripts, etc... I will post a topic about the future of the project
in a few weeks, as I probably won't work on it until June 2007. The only
thing I will do during the next 12 months is the creation of XML files.

Of course, if you want to create a tool to generate xml files, feel free
.-), as long as it doesn't require more work to fix mistakes introduced
by an automatic program that it would with manual xml file creation.
(but I think that if you have time there are more interesting work to do
on ddccontrol .-))

Best regards,

Nicolas

Re: [ddccontrol-devel] Status of next release

[Nicolas B. <ni...@bo...>]

Roberto C. Sanchez wrote:
> I just saw that gcc 4.1 became the default compiler for Debian Etch (the
>  current testing and upcoming release).  I would like to get ddccontrol
> in before the freeze (coming up in a few months).  I just wanted to
> verify that when the version of ddccontrol is released it will build
> cleanly with gcc 4.1.  I won't have time to personally test this for a
> few weeks since I am finishing up my school and will be travelling to a
> conference for a couple of weeks.
>
> Though, I do have the package framework setup and if the new version
> builds cleanly with gcc 4.1, then I will be able to get it uploaded
> relatively quickly.
>   
ddccontrol builds fine, without warning, with gcc-4.1.1 (gentoo).

Best regards,

Nicolas

Re: [ddccontrol-devel] [ddccontrol-users] Could the xml files be auto-generated?

[Nicolas B. <ni...@bo...>]

Hi,

David R Mulligan wrote:
> I was wondering if these files could be auto-generated, tweaked and then
> submitted. It seems that the output of the ddccontrol util is taken at
> face value for the first version so why can't it be used to generate a
> test xml file? Perhaps it could be done with some interaction from the
> user?

That's something I thought about, but unfortunately I think it is too
complicated to do. xml files are not very complicated to create, but it
needs some intelligence and experience about how DDC/CI works (or
doesn't work), which a computer program cannot provide. For example,
these are things I've done to create the database:
- Google, ask if the monitor is a LCD or a CRT (so I don't define absurd
controls like "pincushion" for LCDs)
- see that there is a missing parenthesis in monitor caps (Philips)
- see that a monitor reports strange values for some controls, so ask
the user if the controls really works (like the Samsung 215tw)
- create CAPS manually for an old monitor only supporting DDC/CI
partially (Samsung 173s)
- see that some controls are useful, but not in CAPS (very common for
Samsung)
- ask NEC-Mitsubishi / Fujistu-Siemens about the missing controls (I
have contact with these two manufacturer)
- etc...

xml-file creation has also been really simplified with the introduction
of generic profiles, it is also less important to have full support for
monitor as the user, without having a specific file for his monitor,
already has basic support (like brightness, which is probably the most
wanted control .-)).

> Part of why I am asking is the because of the mistakes made in some of
> the recent xml files

What mistakes ? Please tell me and I would be happy to fix these.

> as well as the fact that I am sure Nicolas would
> like some of his time back to do more interesting things than to parse
> the monitor capability output text to generate xml definition files :)

Of course I would like to do something else, but unfortunately, nothing
is simple with the monitors: controls are far from standard, and even
for a specific manufacturer, the same control sometimes behaves
differently (look at SAMlcd.xml for example), and a lot of monitors are
buggy.

If I had time, I would like to do some work on gddccontrol (add more
full screen patterns for example), add support for read-only controls in
the database (to support rotation for example), allow better integration
with scripts, etc... I will post a topic about the future of the project
in a few weeks, as I probably won't work on it until June 2007. The only
thing I will do during the next 12 months is the creation of XML files.

Of course, if you want to create a tool to generate xml files, feel free
.-), as long as it doesn't require more work to fix mistakes introduced
by an automatic program that it would with manual xml file creation.
(but I think that if you have time there are more interesting work to do
on ddccontrol .-))

Best regards,

Nicolas

[ddccontrol-devel] Status of next release

[Roberto C. S. <ro...@fa...>]

I just saw that gcc 4.1 became the default compiler for Debian Etch (the
 current testing and upcoming release).  I would like to get ddccontrol
in before the freeze (coming up in a few months).  I just wanted to
verify that when the version of ddccontrol is released it will build
cleanly with gcc 4.1.  I won't have time to personally test this for a
few weeks since I am finishing up my school and will be travelling to a
conference for a couple of weeks.

Though, I do have the package framework setup and if the new version
builds cleanly with gcc 4.1, then I will be able to get it uploaded
relatively quickly.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

[ddccontrol-devel] Question on man pages and Spanish translations

[Roberto C. S. <ro...@fa...>]

Hello,

First question:

As part of packaging for Debian, every executable binary requires a
corresponding man page.  Is it OK if I just create a directory called
man under the ddccontrol modules in CVS and add the man pages there?
What is the best way to set this up to make certain that translated man
pages can be added without cluttrering everything up?

Second question:

What is the status of translating the UI into Spanish?  I notice that
there are already a few translations, but Spanish is not one.  Has
someone committed to doing a Spanish translation?  If not, I can start
on them in about a month or so.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

Re: [ddccontrol-devel] Debian packaging, take 2

[Roberto C. S. <ro...@fa...>]

Nicolas Boichat wrote:
> 
> Thank you I know about these problems with gcc 4.0, I fixed them in CVS.
> I think I will release ddccontrol 0.4.2 soon, as I fixed other problems.
> I just need to find some time to do the work.
> 
>> Additionally, gcc-4.1 will shortly become the default for Debian Sid and
>> I think that will only create more problems.
> 
> 
> It shouldn't. Minor versions (for example gcc 3.3 and 3.4) are usually
> not a big problem.
> 
> Best regards,
> 
> Nicolas
> 

OK.  I still have a couple of things left to work out for the Debian
packaging and once the new version comes out and builds cleanly with the
newer gcc, then I will have it uploaded.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

Re: [ddccontrol-devel] Debian packaging, take 2

[Nicolas B. <ni...@bo...>]

Hi Roberto,

Roberto C. Sanchez wrote:
> Hello,
> 
> I finally made some time to work on packaging for Debian.  I have the
> package almost complete, however the build has numerous warnings.  For
> example:
> 
>  i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I..
> -DLOCALEDIR=\"/usr/share/locale\" -I/usr/include/libxml2 -Wall -g -O2
> -Wall -DDATADIR=\"/usr/share/ddccontrol-db\" -DBINDIR=\"/usr/bin\" -MT
> ddcci.lo -MD -MP -MF .deps/ddcci.Tpo -c ddcci.c  -fPIC -DPIC -o
> .libs/ddcci.o
> ddcci.c: In function 'i2c_write':
> ddcci.c:273: warning: pointer targets in passing argument 2 of 'dumphex'
> differ
> in signedness
> ddcci.c:305: warning: pointer targets in passing argument 2 of 'dumphex'
> differ
> in signedness
> ddcci.c: In function 'i2c_read':
> ddcci.c:343: warning: pointer targets in passing argument 2 of 'dumphex'
> differ
> in signedness
> ddcci.c:378: warning: pointer targets in passing argument 2 of 'dumphex'
> differ
> in signedness
> ddcci.c: In function 'ddcci_read_edid':
> ddcci.c:795: warning: pointer targets in passing argument 1 of
> 'snprintf' differ in signedness
> 
> This seems to me to be partly because gcc-4.0 is more strict.  Since
> this is the default compiler in Sid I really need to resolve these
> before I feel comfortable trying to have the package uploaded.

Thank you I know about these problems with gcc 4.0, I fixed them in CVS. 
I think I will release ddccontrol 0.4.2 soon, as I fixed other problems. 
I just need to find some time to do the work.

> Additionally, gcc-4.1 will shortly become the default for Debian Sid and
> I think that will only create more problems.

It shouldn't. Minor versions (for example gcc 3.3 and 3.4) are usually 
not a big problem.

Best regards,

Nicolas

[ddccontrol-devel] Debian packaging, take 2

[Roberto C. S. <ro...@fa...>]

Hello,

I finally made some time to work on packaging for Debian.  I have the
package almost complete, however the build has numerous warnings.  For
example:

 i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I..
-DLOCALEDIR=\"/usr/share/locale\" -I/usr/include/libxml2 -Wall -g -O2
-Wall -DDATADIR=\"/usr/share/ddccontrol-db\" -DBINDIR=\"/usr/bin\" -MT
ddcci.lo -MD -MP -MF .deps/ddcci.Tpo -c ddcci.c  -fPIC -DPIC -o
.libs/ddcci.o
ddcci.c: In function 'i2c_write':
ddcci.c:273: warning: pointer targets in passing argument 2 of 'dumphex'
differ
in signedness
ddcci.c:305: warning: pointer targets in passing argument 2 of 'dumphex'
differ
in signedness
ddcci.c: In function 'i2c_read':
ddcci.c:343: warning: pointer targets in passing argument 2 of 'dumphex'
differ
in signedness
ddcci.c:378: warning: pointer targets in passing argument 2 of 'dumphex'
differ
in signedness
ddcci.c: In function 'ddcci_read_edid':
ddcci.c:795: warning: pointer targets in passing argument 1 of
'snprintf' differ in signedness

This seems to me to be partly because gcc-4.0 is more strict.  Since
this is the default compiler in Sid I really need to resolve these
before I feel comfortable trying to have the package uploaded.
Additionally, gcc-4.1 will shortly become the default for Debian Sid and
I think that will only create more problems.

I have the complete log of the build if anyone is interested:

http://familiasanchez.net/~roberto/ddccontrol-0.4.1_debian_sid_build.log

Regards,

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto

[ddccontrol-devel] Re: [ddccontrol-users] Automatic rotation: Proof of Concept

[Nicolas B. <ni...@bo...>]

Hi Daniel,

First, thank you for your tool, looks very nice, even though I can't 
test it.

Daniel Elstner wrote:
> Hello,
> 
> first, let me thank you for this great piece of software.  I own a
> Samsung SyncMaster 970p and thus would not be able to change the monitor
> setup at all without a tool like ddccontrol.
> 
> Addicted to technical gimmicks as I am, I obviously also wanted to make
> use of the pivot functionality of my flat panel.  But even with a simple
> graphical tool like gnome-randr-applet, having to change the rotation
> setting of the X screen manually each time is highly annoying.  (Just
> try using your mouse with the panel already rotated...  Go figure.)

Quite funny .-)

> Well, the result of the hacking frenzy that followed is attached to this
> mail.  Simply by diff'ing the output of two ddccontrol runs, I found the
> control I need to listen for.  I then put together a tiny C program that
> uses libddccontrol to poll the monitor every second, and XRandR to set
> the screen rotation whenever the panel rotation changed.  This is just a
> proof of concept for now as you have to start the tool manually and keep
> it running all the time.  Nonetheless it works quite well on my system.
> 
> I'd be glad if interested people could pick up this piece and have some
> fun with it, and share the results on this list.  Simple build and usage
> instructions are to be found at the top of the source file.  Thank you!

It will certainly happen.

> However, for a proper solution, a couple of questions need to be
> considered first:
> 
> 1) Is the control index 0xF8 standardized in any way?  If not, it might
> be necessary to add an entry to ddccontrol's monitor database.

No, it is not a standard (values in this range are vendor-specific). 
You're right, an entry must be added in the database. However, there is 
  no support for read-only controls right now, however this is something 
I wanted to add so I'll work on it.

> 2) Is there a better way than polling?  I already tried to keep the
> overhead at a minimum by reducing the work that is done periodically.
> The bash script I initially wrote called ddccontrol every second, which
> caused simply unacceptable overhead for something running in the
> background.  With the current code there are no CPU usage spikes
> noticeable anymore; but nonetheless, it'd be cool if the polling could
> be avoided altogether.

No. I'm almost certain DDC/CI doesn't support interrupts or anything 
like this which could avoid polling. However, as I never had the 
specifications, we could have surprises .-)

> 3) The big question:  Where to put this?  System service,

I don't think it is possible, as you have to attach the application with 
an X server, which probably isn't running when the service starts.

  X itself, gdm,
> addition to gnome-randr-applet,

I don't think Xorg, or Gnome, will accept to depend on ddccontrol .-)

  ddccontrol applet

Could be an idea, but ddccontrol applet depends on Gnome. I think it 
would be a good idea to have support for other window managers, as your 
application doesn't need user interaction.

, whatever?  The goal
> should be to make this as most "out of the box" as possible.

gdm support running scripts even before logging in (see subdirectories 
in /etc/X11/gdm/), so I think it would be a good place to start your 
program. Maybe there is also ways to get an application started at the 
same time as X.

   Of course
> this requires to first get ddccontrol itself into distros :)

This depends on maintainers. On Gentoo, as the work is really small, 
sometimes I make the ebuilds, sometimes others do. Of course, 
integration in other distributions would be very nice, but as I don't 
use them I won't do the work.

> 4) Minor one:  I think libddccontrol should install a .pc file for use
> with pkg-config, in order to ease the burden of linking to it.

Ok I don't think it is an essential feature, and as I don't have much 
time, I won't on it for now. (Of course if you want to provide a patch 
you're welcome .-))

> 5) Do you like the idea?  :-)

Yes a lot!! I would like to get it integrated into the main ddccontrol 
package, so, if you agree, please send me your SourceForge id some I 
will give you developer CVS access. (We should then discuss the name we 
want to give to your app, and discuss about coding guidelines (for 
example, we use tab identation in ddccontrol))

> I probably forgot one issue or another, but that's enough for now
> anyway.  I'll be glad to hear your opinions/suggestions/flames.

Thank you very much,

Best regards,

Nicolas

[ddccontrol-devel] Automatic rotation: Proof of Concept

[Daniel E. <dan...@go...>]

Hello,

first, let me thank you for this great piece of software.  I own a
Samsung SyncMaster 970p and thus would not be able to change the monitor
setup at all without a tool like ddccontrol.

Addicted to technical gimmicks as I am, I obviously also wanted to make
use of the pivot functionality of my flat panel.  But even with a simple
graphical tool like gnome-randr-applet, having to change the rotation
setting of the X screen manually each time is highly annoying.  (Just
try using your mouse with the panel already rotated...  Go figure.)

Well, the result of the hacking frenzy that followed is attached to this
mail.  Simply by diff'ing the output of two ddccontrol runs, I found the
control I need to listen for.  I then put together a tiny C program that
uses libddccontrol to poll the monitor every second, and XRandR to set
the screen rotation whenever the panel rotation changed.  This is just a
proof of concept for now as you have to start the tool manually and keep
it running all the time.  Nonetheless it works quite well on my system.

I'd be glad if interested people could pick up this piece and have some
fun with it, and share the results on this list.  Simple build and usage
instructions are to be found at the top of the source file.  Thank you!

However, for a proper solution, a couple of questions need to be
considered first:

1) Is the control index 0xF8 standardized in any way?  If not, it might
be necessary to add an entry to ddccontrol's monitor database.

2) Is there a better way than polling?  I already tried to keep the
overhead at a minimum by reducing the work that is done periodically.
The bash script I initially wrote called ddccontrol every second, which
caused simply unacceptable overhead for something running in the
background.  With the current code there are no CPU usage spikes
noticeable anymore; but nonetheless, it'd be cool if the polling could
be avoided altogether.

3) The big question:  Where to put this?  System service, X itself, gdm,
addition to gnome-randr-applet, ddccontrol applet, whatever?  The goal
should be to make this as most "out of the box" as possible.  Of course
this requires to first get ddccontrol itself into distros :)

4) Minor one:  I think libddccontrol should install a .pc file for use
with pkg-config, in order to ease the burden of linking to it.

5) Do you like the idea?  :-)

I probably forgot one issue or another, but that's enough for now
anyway.  I'll be glad to hear your opinions/suggestions/flames.

Have fun!
--Daniel

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

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

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

[ddccontrol-devel] DDCcontrol translations

[Nicolas B. <ni...@bo...>]

Hi everybody,

Thanks for answering my request for translators, it is nice to see so
many people interested in doing this job.

Maybe should I present ddccontrol in a few lines, as I don't know if you
already tried this software: It allows to control monitors parameters,
like brightness, constrast, position, etc. without using the buttons on
front of it, i.e. via the VGA/DVI cable.
The distribution is splitted in two packages, ddccontrol (the main
program), and ddccontrol-db (monitor database).

I don't know if you ever worked with CVS and po files, so I'll explain,
sorry for the ones who already know .-)

Tools you need: cvs, automake/autoconf, gettext, make, poedit (or
another tool, or a simple text editor).

First, you need to check-out the sources from the CVS repository (i
can't give you a direct link to the instructions, as SF is down right
now, but they are on the CVS page of ddccontrol project page). Note you
need to perform this operation, and the following ones, on both
ddccontrol and ddccontrol-db modules (there are strings to translate in
the main program, and in the database).

Then run:
# ./autogen.sh
# ./configure (maybe you will need some devel package to make it to
work)
# cd po
# make update-po

If the po file for your language doesn't exist, simply copy
ddccontrol.pot to <YOUR_LANGUAGE_CODE>.po (for example, for French, it
is fr.po) and update the fields in it (like AUTHOR, CHARSET, etc...)

Then open your po file, and translate the strings! I recommend that you
use a tool like poedit (http://poedit.sf.net) to edit it, as it warns
visually you when strings are wrong, and offers spellcheck, but it's
your choice .-)

When you are finished, it would be nice to test if it works by
installing and running the software, but it is not mandatory,
particularly if you don't have the needed hardware (i.e. a monitor
supporting DDC/CI).

Then, I give you two possibilities for sending the completed po files,
either you send them to my personal e-mail, or I give you a CVS write
access (in this case, please send me your SourceForge ID if it is not
already done). The later (CVS) is of course my prefered, as it is less
work for me, but if you don't feel comfortable with CVS, and don't have
time to learn, e-mail is ok too.

Here is a summary of translators with their respective languages and
language codes:
 - nanwushe: Simplified Chinese (zh_CN)
 - Jonathan Farnham: Spanish (es)
 - Gabi1002: German (de) and Spanish (es)
 - Zsolt Pãsztor: Hungarian (hu)

Jonathan and Gabi1002, I don't know if you want to split Spanish
translation between both of us, or maybe it is simpler if Jonathan does
Spanish translation, and Gabi1002 German translation, I let you discuss
this between you, and send me your decision once you have made it.

I suggest that you all subscribe to ddccontrol-devel, particularly if
you have problems to translate some technical strings. So I don't have
to explain 4 times the same term to all of you .-)

Also, as some of you probably have a better English level than mine, it
would be really nice to report English mistakes in the original strings
if you find some.

I think that's all, sorry for the long message, I hope my explanations
were complete, otherwise do not hesitate to contact me (cc-ing the devel
list) if you have questions.

Thanks,

Best regards,

Nicolas

[ddccontrol-devel] DDCcontrol version 0.4.1 released (FC4 compilation error fix)

[Nicolas B. <ni...@bo...>]

Hi again,

I just released DDCcontrol 0.4.1. It fixes the compilation error on
Fedora Core 4 reported by Florin Andrei, and I released a new version as
this may affect other distributions.

Best regards,

Nicolas

[ddccontrol-devel] DDCcontrol version 0.4 and ddccontrol-db-20060308 released

[Nicolas B. <ni...@bo...>]

Hi everybody .-)

I just released a new version of ddccontrol and ddccontrol-db.

The main change is a new database format, using generic profiles (thank
you Oleg for reminding me this old idea). The database now looks nicer,
and I hope I did not break anything, so please test this new version!

Thanks to everybody,

Changelogs:
-----
Version 0.4 - 2006-03-08
 - New database version (3), supporting generic profiles for monitors.
 - Add support for VIA and SiS chipsets (Thanks to Johannes Deisenhofer)
 - Fix memory leaks using valgrind.
 - Fix various compilation errors.
-----
Version 20060308:
 - New database format, using generic profiles.
 - Add support for new monitors:
   + Samsung Syncmaster 970P (Thanks to Martin Kalkman)
   + Dell 2005FPW (Thanks to Miguel)
   + Samsung 770P (Thanks to Mateusz Drach)
   + Samsung 970P analog
   + Samsung 701T
   + Samsung 760BF
   + Samsung 910T
   + Samsung 960BF
   + Samsung SyncMaster 913V (Thanks to Hubai Tamas)
   + Samsung SyncMaster 730BF (Thanks to Gergely Nagy)
   + SUN GDM-5410 (Thanks to "bman")
   + Samsung 740T (Thanks to Guryanov Dmitry)
   + Dell 2405FPW (Thanks to Alexander McLeay)
   + Samsung 920N
 - Complete support for these monitors:
   + Samsung 171P (Thanks to Radoslaw Marcinkowski)
-----

Best regards,

Nicolas

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

[Nicolas B. <ni...@bo...>]

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

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

[Oleg I. V. <ol...@cs...>]

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

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

[Nicolas B. <ni...@bo...>]

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

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

Re: [ddccontrol-devel] Support vor VIA Unichrome and some SIS Chipset

[Nicolas B. <ni...@bo...>]

Hi Jo,

Thank you very much, I commited your patch to the CVS.

I only did small modifications:
 - Added back original author copyright on sis.c (from init301.c in
kernel source).
 - Removed device ID check, i.e. you code will execute on every VIA and
SiS cards. This is not a problem, we do this for every brand, even when
we don't have the documentation.

Best regards,

Nicolas

On Fri, 2006-03-03 at 17:14 +0100, Johannes Deisenhofer wrote:
> Hi,
> 
> I have added support vor VIA Unichrome Chipsets and some SIS chipset to the ddcpci 
> program. Though this probably works for a lot more chipsets, due to lack of 
> documentation, it is limited to those 3 vga cards/chipsets I have access to.
> For the same reason, not all I2C-Busses are probed, for sis only the first.
> 
> Supported hardware:
> 
> 1106/3122 VIA VT8623 [Apollo CLE266] integrated CastleRock graphics
> 1106/3118 VIA S3 Unichrome Pro VGA Adapter
> 1039/6330 SiS [M]661xX/[M]741[GX]/[M]760 PCI/AGP VGA Adapter
> 
> Jo

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

[Nicolas B. <ni...@bo...>]

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

[ddccontrol-devel] Support vor VIA Unichrome and some SIS Chipset

[Johannes D. <jo...@bn...>]

Hi,

I have added support vor VIA Unichrome Chipsets and some SIS chipset to the ddcpci 
program. Though this probably works for a lot more chipsets, due to lack of 
documentation, it is limited to those 3 vga cards/chipsets I have access to.
For the same reason, not all I2C-Busses are probed, for sis only the first.

Supported hardware:

1106/3122 VIA VT8623 [Apollo CLE266] integrated CastleRock graphics
1106/3118 VIA S3 Unichrome Pro VGA Adapter
1039/6330 SiS [M]661xX/[M]741[GX]/[M]760 PCI/AGP VGA Adapter

Jo

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

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

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