ddccontrol-devel — Development list.

Re: [ddccontrol-devel] Panel Applet, libddcci

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

On Fri, Sep 02, 2005 at 11:21:53AM +0200, Nicolas Boichat wrote:
> Hello Roberto,
>=20
> The project will not be splitted in the CVS.
>=20
> But from the packaging point of view, you may want to split the project
> in different parts, for example:
>  - ddccontrol-base: basic command line ddccontrol tool, and=20
> libddccontrol.so
>  - ddccontrol-devel: header files to build apps against libddccontrol.so
> (for the moment it is not needed as no other app use the library)
>  - ddccontrol-gnome: gddccontrol and gnome-ddcc-applet
>=20
> You may want to create even more packages (Christian presented an
> alternative), or just create one for the moment.
>=20
OK.  Thanks for the clarification.  I have become very busy with my
final projects and final exams.  I jave part of the packaging work
completed already.  When I finish exams in the middle of next week, I
will return finishing up the packaging and check the files in on teh
branch I created in CVS.

-Roberto

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

Re: [ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

Am Freitag, den 02.09.2005, 11:37 +0200 schrieb Nicolas Boichat:
> Hello Christian,
> 
> On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote:
> > > > i'm currently working on a panel applet for gnome, with allows quick
> > > > changeing of profiles created with gddccontrol.
> > > 
> > > Nice idea .-) One thing you should take care of is multi-screen (which
> > > monitor are you controlling?).
> > yes i am aware of this, the applet is now working with one monitor only
> > (first one thats found), but i intend to make an config dialog to chose
> > the monitor.
> > > 
> > > > while doing this i noticed libddcci is build as a static library.
> > > > as i needed it's functionality in my applet i changed the makefiles (and
> > > > headers) to build a shared library and install it in $PREFIX/lib
> > > > (headers in $prefix/include/ddcci)
> > > 
> > > There is no problem about it. My only concern is about two applications
> > > accessing the monitors at the same time. It could create huge problems
> > > (particularly with ddcpci)... I think we need a mechanism to lock and
> > > unlock the libraries, but I've no experience on it. Any idea??
> > not only the library must be locked, but other applications also need to
> > get informed of changes.
> > or do you mean not allowing to run two applications at the same time?
> 
> An easy way of doing this thing, which doesn't requires the apps to be
> "informed", would be:
>  - When ddccontrol or gddccontrol run, it locks the library, so no other
> app can access DDC/CI. (so you can't change profile in ddcc-applet)
>  - When ddcc-applet, it doesn't lock the library, unless when it is
> changing of profile.
> 
> But again, I don't know how to do this... I'll try to find
> informations...
> 

is it requrired that the whole library is locked, or must just be
ensured, that only one library function is executed at a time?

i've experienced no problems so far running both apps the same time,
exept the information they are showing getting out of sync.

what kind of problems do you expect? maybe just adding protection to
some critical functions is enough.

-- 
Christian Schilling <csc...@gm...>

Re: [ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

Am Freitag, den 02.09.2005, 11:37 +0200 schrieb Nicolas Boichat:
> Hello Christian,
> 
> On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote:
> > > > i'm currently working on a panel applet for gnome, with allows quick
> > > > changeing of profiles created with gddccontrol.
> > > 
> > > Nice idea .-) One thing you should take care of is multi-screen (which
> > > monitor are you controlling?).
> > yes i am aware of this, the applet is now working with one monitor only
> > (first one thats found), but i intend to make an config dialog to chose
> > the monitor.
> > > 
> > > > while doing this i noticed libddcci is build as a static library.
> > > > as i needed it's functionality in my applet i changed the makefiles (and
> > > > headers) to build a shared library and install it in $PREFIX/lib
> > > > (headers in $prefix/include/ddcci)
> > > 
> > > There is no problem about it. My only concern is about two applications
> > > accessing the monitors at the same time. It could create huge problems
> > > (particularly with ddcpci)... I think we need a mechanism to lock and
> > > unlock the libraries, but I've no experience on it. Any idea??
> > not only the library must be locked, but other applications also need to
> > get informed of changes.
> > or do you mean not allowing to run two applications at the same time?
> 
> An easy way of doing this thing, which doesn't requires the apps to be
> "informed", would be:
>  - When ddccontrol or gddccontrol run, it locks the library, so no other
> app can access DDC/CI. (so you can't change profile in ddcc-applet)
>  - When ddcc-applet, it doesn't lock the library, unless when it is
> changing of profile.
> 
> But again, I don't know how to do this... I'll try to find
> informations...
> 
> > > > now i'd suggest to split the project into seperate modules:
> > > > - libgddcc (or libddcci??)
> > > What do you think of libddccontrol ? (the so file would be
> > > libddccontrol.so, and be linked with -lddccontrol)
> > 
> > yes this name has the atvantage of being a little more self explaining
> > 
> > > > - ddccontrol
> > > > - gddccontrol
> > > > - ddcc-applet
> > > Maybe should you a a "g" somewhere, because there are also KDE applets I think.
> > 
> > maybe gnome-ddcc-applet
> > 
> > > 
> > > Now, about the idea of splitting the project in modules, I'm not sure of
> > > what you mean... Do you suggest to split the project in different
> > > tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> > > ddcontrol-db) are already enough to download, and as their size is
> > > relatively limited I don't see any problem (if you only want some parts
> > > of ddccontrol, you can enable them with configure flags).
> > > Of course, if a packager want to split the project, there is no problem
> > > (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> > > ddccontrol-devel...).
> > 
> > yes, i meant different tarballs, but mainly because i think it should be
> > packaged this way in debs and rpms.
> > 
> > 
> > > I think you can commit your modifications. Please just add a tag before
> > > doing it ("cvs tag Before_shared_lib" for example).
> > 
> > ok, ill do this.
> > i think if the headers are "pubilc" and maybe used in different
> > applications, not only functions but also types should be prefixed
> > ("DdcciProfile" instead of "struct profile") to avoid naming conflicts
> > with other headers/libs.
> 
> ddcci_profile is better (more GNU-styled .-)). I'll work on this.
> 
> Concerning ddcc-applet, I first had some problems to build it (libtool
> was missing, you added it, then the wrong version was installed), but
> now it builds and gets installed... Could you just explain me how to add
> it in gnome panels??

It should be listed in Gnome's "add to panel" dialog after installation.
Hower if it's not it properbly means the *.server file got in the wrong
location.
On Debian all *.server files are placed in /usr/lib/bonobo/servers.
in the makefile i secified to install it in $(libdir)/bonobo/server (i
configure with --prefix="/usr")


-- 
Christian Schilling <csc...@gm...>

Re: [ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

Am Freitag, den 02.09.2005, 11:37 +0200 schrieb Nicolas Boichat:
> Hello Christian,
> 
> On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote:
> > > > i'm currently working on a panel applet for gnome, with allows quick
> > > > changeing of profiles created with gddccontrol.
> > > 
> > > Nice idea .-) One thing you should take care of is multi-screen (which
> > > monitor are you controlling?).
> > yes i am aware of this, the applet is now working with one monitor only
> > (first one thats found), but i intend to make an config dialog to chose
> > the monitor.
> > > 
> > > > while doing this i noticed libddcci is build as a static library.
> > > > as i needed it's functionality in my applet i changed the makefiles (and
> > > > headers) to build a shared library and install it in $PREFIX/lib
> > > > (headers in $prefix/include/ddcci)
> > > 
> > > There is no problem about it. My only concern is about two applications
> > > accessing the monitors at the same time. It could create huge problems
> > > (particularly with ddcpci)... I think we need a mechanism to lock and
> > > unlock the libraries, but I've no experience on it. Any idea??
> > not only the library must be locked, but other applications also need to
> > get informed of changes.
> > or do you mean not allowing to run two applications at the same time?
> 
> An easy way of doing this thing, which doesn't requires the apps to be
> "informed", would be:
>  - When ddccontrol or gddccontrol run, it locks the library, so no other
> app can access DDC/CI. (so you can't change profile in ddcc-applet)
>  - When ddcc-applet, it doesn't lock the library, unless when it is
> changing of profile.
> 
> But again, I don't know how to do this... I'll try to find
> informations...
> 

is it requrired that the whole library is locked, or must just be
ensured, that only one library function is executed at a time?

i've experienced no problems so far running both apps the same time,
exept the information they are showing getting out of sync.

what kind of problems do you expect? maybe just adding protection to
some critical functions is enough.

-- 
Christian Schilling <csc...@gm...>

Re: [ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

Am Freitag, den 02.09.2005, 11:37 +0200 schrieb Nicolas Boichat:
> Hello Christian,
> 
> On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote:
> > > > i'm currently working on a panel applet for gnome, with allows quick
> > > > changeing of profiles created with gddccontrol.
> > > 
> > > Nice idea .-) One thing you should take care of is multi-screen (which
> > > monitor are you controlling?).
> > yes i am aware of this, the applet is now working with one monitor only
> > (first one thats found), but i intend to make an config dialog to chose
> > the monitor.
> > > 
> > > > while doing this i noticed libddcci is build as a static library.
> > > > as i needed it's functionality in my applet i changed the makefiles (and
> > > > headers) to build a shared library and install it in $PREFIX/lib
> > > > (headers in $prefix/include/ddcci)
> > > 
> > > There is no problem about it. My only concern is about two applications
> > > accessing the monitors at the same time. It could create huge problems
> > > (particularly with ddcpci)... I think we need a mechanism to lock and
> > > unlock the libraries, but I've no experience on it. Any idea??
> > not only the library must be locked, but other applications also need to
> > get informed of changes.
> > or do you mean not allowing to run two applications at the same time?
> 
> An easy way of doing this thing, which doesn't requires the apps to be
> "informed", would be:
>  - When ddccontrol or gddccontrol run, it locks the library, so no other
> app can access DDC/CI. (so you can't change profile in ddcc-applet)
>  - When ddcc-applet, it doesn't lock the library, unless when it is
> changing of profile.
> 
> But again, I don't know how to do this... I'll try to find
> informations...
> 
> > > > now i'd suggest to split the project into seperate modules:
> > > > - libgddcc (or libddcci??)
> > > What do you think of libddccontrol ? (the so file would be
> > > libddccontrol.so, and be linked with -lddccontrol)
> > 
> > yes this name has the atvantage of being a little more self explaining
> > 
> > > > - ddccontrol
> > > > - gddccontrol
> > > > - ddcc-applet
> > > Maybe should you a a "g" somewhere, because there are also KDE applets I think.
> > 
> > maybe gnome-ddcc-applet
> > 
> > > 
> > > Now, about the idea of splitting the project in modules, I'm not sure of
> > > what you mean... Do you suggest to split the project in different
> > > tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> > > ddcontrol-db) are already enough to download, and as their size is
> > > relatively limited I don't see any problem (if you only want some parts
> > > of ddccontrol, you can enable them with configure flags).
> > > Of course, if a packager want to split the project, there is no problem
> > > (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> > > ddccontrol-devel...).
> > 
> > yes, i meant different tarballs, but mainly because i think it should be
> > packaged this way in debs and rpms.
> > 
> > 
> > > I think you can commit your modifications. Please just add a tag before
> > > doing it ("cvs tag Before_shared_lib" for example).
> > 
> > ok, ill do this.
> > i think if the headers are "pubilc" and maybe used in different
> > applications, not only functions but also types should be prefixed
> > ("DdcciProfile" instead of "struct profile") to avoid naming conflicts
> > with other headers/libs.
> 
> ddcci_profile is better (more GNU-styled .-)). I'll work on this.
> 
> Concerning ddcc-applet, I first had some problems to build it (libtool
> was missing, you added it, then the wrong version was installed), but
> now it builds and gets installed... Could you just explain me how to add
> it in gnome panels??

It should be listed in Gnome's "add to panel" dialog after installation.
Hower if it's not it properbly means the *.server file got in the wrong
location.
On Debian all *.server files are placed in /usr/lib/bonobo/servers.
in the makefile i secified to install it in $(libdir)/bonobo/server (i
configure with --prefix="/usr")


-- 
Christian Schilling <csc...@gm...>

Re: [ddccontrol-devel] Panel Applet, libddcci

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

Hello Christian,

On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote:
> > > i'm currently working on a panel applet for gnome, with allows quick
> > > changeing of profiles created with gddccontrol.
> > 
> > Nice idea .-) One thing you should take care of is multi-screen (which
> > monitor are you controlling?).
> yes i am aware of this, the applet is now working with one monitor only
> (first one thats found), but i intend to make an config dialog to chose
> the monitor.
> > 
> > > while doing this i noticed libddcci is build as a static library.
> > > as i needed it's functionality in my applet i changed the makefiles (and
> > > headers) to build a shared library and install it in $PREFIX/lib
> > > (headers in $prefix/include/ddcci)
> > 
> > There is no problem about it. My only concern is about two applications
> > accessing the monitors at the same time. It could create huge problems
> > (particularly with ddcpci)... I think we need a mechanism to lock and
> > unlock the libraries, but I've no experience on it. Any idea??
> not only the library must be locked, but other applications also need to
> get informed of changes.
> or do you mean not allowing to run two applications at the same time?

An easy way of doing this thing, which doesn't requires the apps to be
"informed", would be:
 - When ddccontrol or gddccontrol run, it locks the library, so no other
app can access DDC/CI. (so you can't change profile in ddcc-applet)
 - When ddcc-applet, it doesn't lock the library, unless when it is
changing of profile.

But again, I don't know how to do this... I'll try to find
informations...

> > > now i'd suggest to split the project into seperate modules:
> > > - libgddcc (or libddcci??)
> > What do you think of libddccontrol ? (the so file would be
> > libddccontrol.so, and be linked with -lddccontrol)
> 
> yes this name has the atvantage of being a little more self explaining
> 
> > > - ddccontrol
> > > - gddccontrol
> > > - ddcc-applet
> > Maybe should you a a "g" somewhere, because there are also KDE applets I think.
> 
> maybe gnome-ddcc-applet
> 
> > 
> > Now, about the idea of splitting the project in modules, I'm not sure of
> > what you mean... Do you suggest to split the project in different
> > tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> > ddcontrol-db) are already enough to download, and as their size is
> > relatively limited I don't see any problem (if you only want some parts
> > of ddccontrol, you can enable them with configure flags).
> > Of course, if a packager want to split the project, there is no problem
> > (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> > ddccontrol-devel...).
> 
> yes, i meant different tarballs, but mainly because i think it should be
> packaged this way in debs and rpms.
> 
> 
> > I think you can commit your modifications. Please just add a tag before
> > doing it ("cvs tag Before_shared_lib" for example).
> 
> ok, ill do this.
> i think if the headers are "pubilc" and maybe used in different
> applications, not only functions but also types should be prefixed
> ("DdcciProfile" instead of "struct profile") to avoid naming conflicts
> with other headers/libs.

ddcci_profile is better (more GNU-styled .-)). I'll work on this.

Concerning ddcc-applet, I first had some problems to build it (libtool
was missing, you added it, then the wrong version was installed), but
now it builds and gets installed... Could you just explain me how to add
it in gnome panels??

Best regards,

Nicolas

Re: [ddccontrol-devel] Panel Applet, libddcci

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

Hello Roberto,

Back at work... (sorry for the delay)

On Thu, 2005-08-25 at 13:35 -0400, Roberto C. Sanchez wrote:
> On Thu, Aug 25, 2005 at 03:48:26PM +0200, Nicolas Boichat wrote:
> > 
> > Now, about the idea of splitting the project in modules, I'm not sure of
> > what you mean... Do you suggest to split the project in different
> > tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> > ddcontrol-db) are already enough to download, and as their size is
> > relatively limited I don't see any problem (if you only want some parts
> > of ddccontrol, you can enable them with configure flags).
> > Of course, if a packager want to split the project, there is no problem
> > (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> > ddccontrol-devel...).
> > 
> I would also like to know about this.  I am working on the Debian
> packaging and should have something ready by this weekend.  However, if
> the project is going to be split into different packages, I think it may
> be worthwhile to wait.  What do you think?

The project will not be splitted in the CVS.

But from the packaging point of view, you may want to split the project
in different parts, for example:
 - ddccontrol-base: basic command line ddccontrol tool, and 
libddccontrol.so
 - ddccontrol-devel: header files to build apps against libddccontrol.so
(for the moment it is not needed as no other app use the library)
 - ddccontrol-gnome: gddccontrol and gnome-ddcc-applet

You may want to create even more packages (Christian presented an
alternative), or just create one for the moment.

Best regards,

Nicolas

Re: [ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

> > i'm currently working on a panel applet for gnome, with allows quick
> > changeing of profiles created with gddccontrol.
> 
> Nice idea .-) One thing you should take care of is multi-screen (which
> monitor are you controlling?).
yes i am aware of this, the applet is now working with one monitor only
(first one thats found), but i intend to make an config dialog to chose
the monitor.
> 
> > while doing this i noticed libddcci is build as a static library.
> > as i needed it's functionality in my applet i changed the makefiles (and
> > headers) to build a shared library and install it in $PREFIX/lib
> > (headers in $prefix/include/ddcci)
> 
> There is no problem about it. My only concern is about two applications
> accessing the monitors at the same time. It could create huge problems
> (particularly with ddcpci)... I think we need a mechanism to lock and
> unlock the libraries, but I've no experience on it. Any idea??
not only the library must be locked, but other applications also need to
get informed of changes.
or do you mean not allowing to run two applications at the same time?
> 
> > now i'd suggest to split the project into seperate modules:
> > - libgddcc (or libddcci??)
> What do you think of libddccontrol ? (the so file would be
> libddccontrol.so, and be linked with -lddccontrol)

yes this name has the atvantage of being a little more self explaining

> > - ddccontrol
> > - gddccontrol
> > - ddcc-applet
> Maybe should you a a "g" somewhere, because there are also KDE applets I think.

maybe gnome-ddcc-applet

> 
> Now, about the idea of splitting the project in modules, I'm not sure of
> what you mean... Do you suggest to split the project in different
> tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> ddcontrol-db) are already enough to download, and as their size is
> relatively limited I don't see any problem (if you only want some parts
> of ddccontrol, you can enable them with configure flags).
> Of course, if a packager want to split the project, there is no problem
> (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> ddccontrol-devel...).

yes, i meant different tarballs, but mainly because i think it should be
packaged this way in debs and rpms.


> I think you can commit your modifications. Please just add a tag before
> doing it ("cvs tag Before_shared_lib" for example).

ok, ill do this.
i think if the headers are "pubilc" and maybe used in different
applications, not only functions but also types should be prefixed
("DdcciProfile" instead of "struct profile") to avoid naming conflicts
with other headers/libs.



-- 
Christian Schilling <csc...@gm...>

Re: [ddccontrol-devel] Panel Applet, libddcci

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

On Thu, Aug 25, 2005 at 03:48:26PM +0200, Nicolas Boichat wrote:
>=20
> Now, about the idea of splitting the project in modules, I'm not sure of
> what you mean... Do you suggest to split the project in different
> tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
> ddcontrol-db) are already enough to download, and as their size is
> relatively limited I don't see any problem (if you only want some parts
> of ddccontrol, you can enable them with configure flags).
> Of course, if a packager want to split the project, there is no problem
> (you often see this with RPMs: ddccontrol-lib, ddccontrol,
> ddccontrol-devel...).
>=20
I would also like to know about this.  I am working on the Debian
packaging and should have something ready by this weekend.  However, if
the project is going to be split into different packages, I think it may
be worthwhile to wait.  What do you think?

-Roberto

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

Re: [ddccontrol-devel] Panel Applet, libddcci

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

Hello Christian,

Nice to hear again from you .-)

On Tue, 2005-08-23 at 20:15 +0200, Christian Schilling wrote:
> hello,
> 
> first off, sorry for beeing off the project for so long my spare time
> was quite limited (a-levels...)

No problem .-)

> i'm currently working on a panel applet for gnome, with allows quick
> changeing of profiles created with gddccontrol.

Nice idea .-) One thing you should take care of is multi-screen (which
monitor are you controlling?).

> while doing this i noticed libddcci is build as a static library.
> as i needed it's functionality in my applet i changed the makefiles (and
> headers) to build a shared library and install it in $PREFIX/lib
> (headers in $prefix/include/ddcci)

There is no problem about it. My only concern is about two applications
accessing the monitors at the same time. It could create huge problems
(particularly with ddcpci)... I think we need a mechanism to lock and
unlock the libraries, but I've no experience on it. Any idea??

> now i'd suggest to split the project into seperate modules:
> - libgddcc (or libddcci??)
What do you think of libddccontrol ? (the so file would be
libddccontrol.so, and be linked with -lddccontrol)
> - ddccontrol
> - gddccontrol
> - ddcc-applet
Maybe should you a a "g" somewhere, because there are also KDE applets I think.

Now, about the idea of splitting the project in modules, I'm not sure of
what you mean... Do you suggest to split the project in different
tarballs?? If so, I disagree. I think two tarballs (ddccontrol and
ddcontrol-db) are already enough to download, and as their size is
relatively limited I don't see any problem (if you only want some parts
of ddccontrol, you can enable them with configure flags).
Of course, if a packager want to split the project, there is no problem
(you often see this with RPMs: ddccontrol-lib, ddccontrol,
ddccontrol-devel...).

> another benefit of making libddcc a seperate package would be, that fo
> instance someone could write "kddccontrol",

If someone want to write kddccontrol, it would very probably be
integrated into the project.

> or build the funktionality
> into applications like video players (automaticly change to "movie"
> profile, when fullscreen video playback is started)..and so on..

Yes, that's a good idea.

> what do you think about this idea?

I think you can commit your modifications. Please just add a tag before
doing it ("cvs tag Before_shared_lib" for example).

Thanks for working again on this project.

Best regards,

Nicolas

[ddccontrol-devel] Panel Applet, libddcci

[Christian S. <csc...@gm...>]

hello,

first off, sorry for beeing off the project for so long my spare time
was quite limited (a-levels...)

i'm currently working on a panel applet for gnome, with allows quick
changeing of profiles created with gddccontrol.

while doing this i noticed libddcci is build as a static library.
as i needed it's functionality in my applet i changed the makefiles (and
headers) to build a shared library and install it in $PREFIX/lib
(headers in $prefix/include/ddcci)

now i'd suggest to split the project into seperate modules:
- libgddcc (or libddcci??)
- ddccontrol
- gddccontrol
- ddcc-applet

another benefit of making libddcc a seperate package would be, that fo
instance someone could write "kddccontrol", or build the funktionality
into applications like video players (automaticly change to "movie"
profile, when fullscreen video playback is started)..and so on..

what do you think about this idea?

Regards,
Christian

[ddccontrol-devel] DDCcontrol version 0.2 and ddccontrol-db-20050813 released

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

Hello,

I just released ddccontrol-0.2 and ddccontrol-db-20050813.

Changes in ddccontrol-0.2:
 - Major changes in gddccontrol:
  + Add restore button for each control.
  + Add refresh button, and refresh all controls when needed.
  + Add support for profiles to save some controls values and restore them later.
  + Add a fullscreen pattern to adjust brightness and contrast.
 - New database version, please upgrade ddccontrol-db.
---

Changes in ddccontrol-db-20050813:
 - Add support for Samsung SyncMaster 912N and 712N.
 - Add basic fullscreen patterns support.
 - New db version (add refresh parameter).
---

Comments are welcome, particularly on new features I added to gddccontrol (profiles, fullscreen pattern), are they easy to use? Could they be improved?

Probably some people on these lists know more than me about color calibration (That's not difficult as I know nothing about it .-)).
If so, could you please confirm that the brightness/contrast fullscreen pattern and instructions are valid?

Best regards,

Nicolas

Re: [ddccontrol-devel] DDCcontrol and Intel 82865G Integrated Graphics Controller

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

Hi Will,

Thanks for the infos, we'll see if we can do something with them.

Could you please send me the output of "lspci -v -v"?

Best regards,

Nicolas

On Sat, 2005-07-23 at 17:23 -0500, William Hollingworth wrote:
> Hi Nicolas
> 
> Great to see Intel support I have tried it on a couple of machines and in 
> general it works great with  my 82865G Integrated Graphics Controller and 
> an analog DSUB15 connector.
> 
> However this system has an Intel specific AGP daughter card (it's not a 
> full video card, just DVI drivers) that has DVI output.
> 
> With a monitor connected to that card I can't communicate with the display 
> using either GPIOA or GPIOB. Communications is always routed to the DSUB15 
> connector.
> 
> I had a look through the Intel docs and it seems there is MDDC_CLK and 
> MDDC_DATA (also MDVI_CLK and MDVI_DATA) for communicating with the monitor 
> on the DVI connector. Info as follows:
> -------------------------------
> DDC (Display Data Channel)
> The multiplexed digital display interface uses the MDVI_CLK and MDVI_DATA 
> signals to interrogate the panel. The GMCH supports the DDC2B protocol to 
> initiate the transfer of EDID data. The multiplexed digital display 
> interface uses the M_I2C bus to interrogate the external
> transmitter. A third set of signals (MDDC_CLK and MDDC_DATA) is available 
> for a variety of
> purposes. They can be used as a second DDC pair when two TMDS transmitters 
> are used, or as a second I2C pair if there are multiple devices (e.g., PROM 
> and DVO device) that need I2C and there is a speed or addressing conflict.
> 
> The GMCH implements a hardware GMBus controller that can be used to control 
> these signals.
> This allows higher speed transactions (up to 400 kHz) on theses lines than 
> was allowed with
> previous software centric 'bit-bashing' techniques.
> -------------------------------
> 
> However I haven't been able to find any programming info (register offsets 
> etc.) for this anywhere.
> 
> Has anyone got any info on this?
> 
> Thanks
> 
> Will

-- 
Nicolas Boichat <ni...@bo...>

[ddccontrol-devel] DDCcontrol and Intel 82865G Integrated Graphics Controller

[William H. <wi...@ai...>]

Hi Nicolas

Great to see Intel support I have tried it on a couple of machines and in 
general it works great with  my 82865G Integrated Graphics Controller and 
an analog DSUB15 connector.

However this system has an Intel specific AGP daughter card (it's not a 
full video card, just DVI drivers) that has DVI output.

With a monitor connected to that card I can't communicate with the display 
using either GPIOA or GPIOB. Communications is always routed to the DSUB15 
connector.

I had a look through the Intel docs and it seems there is MDDC_CLK and 
MDDC_DATA (also MDVI_CLK and MDVI_DATA) for communicating with the monitor 
on the DVI connector. Info as follows:
-------------------------------
DDC (Display Data Channel)
The multiplexed digital display interface uses the MDVI_CLK and MDVI_DATA 
signals to interrogate the panel. The GMCH supports the DDC2B protocol to 
initiate the transfer of EDID data. The multiplexed digital display 
interface uses the M_I2C bus to interrogate the external
transmitter. A third set of signals (MDDC_CLK and MDDC_DATA) is available 
for a variety of
purposes. They can be used as a second DDC pair when two TMDS transmitters 
are used, or as a second I2C pair if there are multiple devices (e.g., PROM 
and DVO device) that need I2C and there is a speed or addressing conflict.

The GMCH implements a hardware GMBus controller that can be used to control 
these signals.
This allows higher speed transactions (up to 400 kHz) on theses lines than 
was allowed with
previous software centric 'bit-bashing' techniques.
-------------------------------

However I haven't been able to find any programming info (register offsets 
etc.) for this anywhere.

Has anyone got any info on this?

Thanks

Will

At 06:14 PM 7/15/2005 +0200, Nicolas Boichat wrote:
>Hello,
>
>I just released DDCControl 0.1.3 and ddccontrol-db-20050715.
>
>Changes in ddccontrol-0.1.3:
>  - Add support for i810/i815/i830/i845/i855/i865/i915/i945 chipsets,
>     thanks to Chernyavskyy Valentin for his tests.
>  - Add Russian translation, thanks to Sergei Epiphanov.
>---
>
>Changes in ddccontrol-db-20050715:
>  - Add Samsung SyncMaster 173P Plus support.
>  - Add support for the Fujitsu Siemens P17-2, P19-2 and P20-2 (thanks to
>Olaf Tauber, and thanks to Johann Leonhardmair of Fujitsu Siemens)
>  - Add Russian translation, thanks to Sergei Epiphanov.
>---
>
>Best regards,
>
>Nicolas Boichat
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>ddccontrol-devel mailing list
>ddc...@li...
>https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel

[ddccontrol-devel] DDCcontrol version 0.1.3 and ddccontrol-db-20050715 released

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

Hello,

I just released DDCControl 0.1.3 and ddccontrol-db-20050715.

Changes in ddccontrol-0.1.3:
 - Add support for i810/i815/i830/i845/i855/i865/i915/i945 chipsets,
    thanks to Chernyavskyy Valentin for his tests.
 - Add Russian translation, thanks to Sergei Epiphanov.
---

Changes in ddccontrol-db-20050715:
 - Add Samsung SyncMaster 173P Plus support.
 - Add support for the Fujitsu Siemens P17-2, P19-2 and P20-2 (thanks to
Olaf Tauber, and thanks to Johann Leonhardmair of Fujitsu Siemens)
 - Add Russian translation, thanks to Sergei Epiphanov.
---

Best regards,

Nicolas Boichat

Re: [ddccontrol-devel] MEL4632 [Mitsubishi Diamond Pro 2070 SB]

[n001 <n0...@se...>]

J'avais oubli=E9 d'attacher le fichier...

--=20
Nicolas Dimitrijevic - SARL Sengena - http://www.sengena.com/
Beauvallon 15 - 213, ch de Morgiou - 13009 Marseille - France
tel: +33 (0)4 91 40 46 50           mob: +33 (0)6 68 81 54 56

[ddccontrol-devel] MEL4632 [Mitsubishi Diamond Pro 2070 SB]

[n001 <n0...@se...>]

Salut,

J'ai test=E9 sur un Mitsubishi Diamond Pro 2070 SB, ca marche, sur
l'entr=E9e 1 comme sur la 2.
J'ai copi=E9 le fichier MEL4513.xml en MEL4632.xml pour avoir un peu de
r=E9sulat, =E9vidament, ca n'a pas l'air exactement pareil:

Les parametres du MEL4513 suivant ne fonctionnent pas:
- Coussin vertical
- Balance du coussin horizontal
- Lin=E9arit=E9 horizontale
- Balance de la lin=E9arit=E9 horizontale

Les langues ne correspondent pas non plus: (par exemple l'espagnol
correspond au francais sur mon =E9cran)

En fichier attach=E9, le dump de ddccontrol -p -c -d &> ddccontrol.dump

Je suis =E0 votre disposition pour plus d'infos si n=E9cessaire.


--=20
Nicolas Dimitrijevic - SARL Sengena - http://www.sengena.com/
Beauvallon 15 - 213, ch de Morgiou - 13009 Marseille - France
tel: +33 (0)4 91 40 46 50           mob: +33 (0)6 68 81 54 56

[ddccontrol-devel] DDCcontrol version 0.1.2 released

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

Hello,

I just released DDCControl 0.1.2, because there was a compile error in
0.1.1 which affected Fedora Core 3, and probably other main Linux
distributions.

ChangeLog :
 - Fix a compilation error in Fedora Core 3.

Best regards,

Nicolas

[ddccontrol-devel] DDCcontrol version 0.1.1 released

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

Hello,

I just released DDCControl 0.1.1.

ChangeLog :
 - Add support for newest nVidia cards (e.g. GeForce 6200 TC).
 - Build ddcpci statically for security reasons.
 - Add status messages when gddccontrol loads.
 - Display less error messages when devices are not usable.
 - Fix compile error with latest kernel headers.
 - Other minor fixes.

Best regards,

Nicolas

[ddccontrol-devel] DDCcontrol version 0.1 released

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

Hello,

I just released the first official version of DDCcontrol.

For more information, go to the new project website:
http://ddccontrol.sourceforge.net/

Best regards,

Nicolas Boichat

Re: [ddccontrol-devel] ddccontrol website and documentation

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

Hello,

On Sun, 2005-03-27 at 13:46 +0400, Oleg I. Vdovikin wrote:
> Nicolas,
> 
>     good work.

Thank you.

> One visible problem: at the left there is a "Last updated: " 
> string, which is included to the <span class="footdate"> tag, the problem is 
> that footdate is not defined and this results in very small font in the IE.

Yes, right, the css font size of footdate was too small... It also
occured with mozilla/firefox. I fixed it.

>     Also, as for keywords - this is that I've got at my site (according to 
> webalizer).
> 
> 10 7 0.80% ddc/ci
> 12 6 0.69% ddcci
> 13 6 0.69% ddccontrol
> 14 6 0.69% magictune linux

That's a good idea, I get the same keywords at my site. I updated the
list.

Best regards,

Nicolas

> ----- Original Message ----- 
> From: "Nicolas Boichat" <ni...@bo...>
> To: "ddccontrol devel list" <ddc...@li...>
> Sent: Saturday, March 26, 2005 7:42 PM
> Subject: [ddccontrol-devel] ddccontrol website and documentation
> 
> 
> > Hello,
> >
> > I started to work on DDCcontrol website and documentation, the result
> > can be seen there:
> >
> > http://ddccontrol.sourceforge.net/
> >
> > I used DocBook for the documentation, and DocBook Website extension for
> > the website. There is now a new module, ddccontrol-web, on the CVS,
> > which is a copy of the website content.
> >
> > Comments and corrections are welcome.
> >
> > By the way, I will release a first version of ddccontrol on the
> > beginning of the next week, with source tarballs we will probably get
> > more user feedbacks...
> >
> > Happy Easter .-)
> >
> > Best regards,
> >
> > Nicolas
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > ddccontrol-devel mailing list
> > ddc...@li...
> > https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel
> > 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> ddccontrol-devel mailing list
> ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel
> 
-- 
Nicolas Boichat <ni...@bo...>

Re: [ddccontrol-devel] ddccontrol website and documentation

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

Nicolas,

    good work. One visible problem: at the left there is a "Last updated: " 
string, which is included to the <span class="footdate"> tag, the problem is 
that footdate is not defined and this results in very small font in the IE.

    Also, as for keywords - this is that I've got at my site (according to 
webalizer).

10 7 0.80% ddc/ci
12 6 0.69% ddcci
13 6 0.69% ddccontrol
14 6 0.69% magictune linux

Regards,
Oleg.

----- Original Message ----- 
From: "Nicolas Boichat" <ni...@bo...>
To: "ddccontrol devel list" <ddc...@li...>
Sent: Saturday, March 26, 2005 7:42 PM
Subject: [ddccontrol-devel] ddccontrol website and documentation


> Hello,
>
> I started to work on DDCcontrol website and documentation, the result
> can be seen there:
>
> http://ddccontrol.sourceforge.net/
>
> I used DocBook for the documentation, and DocBook Website extension for
> the website. There is now a new module, ddccontrol-web, on the CVS,
> which is a copy of the website content.
>
> Comments and corrections are welcome.
>
> By the way, I will release a first version of ddccontrol on the
> beginning of the next week, with source tarballs we will probably get
> more user feedbacks...
>
> Happy Easter .-)
>
> Best regards,
>
> Nicolas
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> ddccontrol-devel mailing list
> ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddccontrol-devel
> 

[ddccontrol-devel] ddccontrol website and documentation

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

Hello,

I started to work on DDCcontrol website and documentation, the result
can be seen there:

http://ddccontrol.sourceforge.net/

I used DocBook for the documentation, and DocBook Website extension for
the website. There is now a new module, ddccontrol-web, on the CVS,
which is a copy of the website content.

Comments and corrections are welcome.

By the way, I will release a first version of ddccontrol on the
beginning of the next week, with source tarballs we will probably get
more user feedbacks...

Happy Easter .-)

Best regards,

Nicolas

Re: [ddccontrol-devel] gddccontrol

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

Hello,

Selon Christian Schilling <csc...@gm...>:
> Hello
>
> I changed all indents to tabs (and using 8 space tabs on the project to
> make sure the code looks the same ;-))
>
> Im now using commit.sh, too.

Thank you.

> I don't think a mailing list for commit notification is really
> necessary, at least not for me. Concerning the ChangeLog, i don't think
> i hurts to have autogenerated one, and we can still write one by hand.

Ok.

> now about the programm itself, i think the next changes could be adding
> a menu bar at the top, and adding support for profiles.

These are very nice additions.

I'll be on holiday during the next 3 weeks (I'll return on March 3), so I won't
work on ddccontrol, but I'll read my emails from time to time so if you have
questions I'll try to answer.

Best regards,

Nicolas

Re: [ddccontrol-devel] gddccontrol

[Christian S. <csc...@gm...>]

Hello

I changed all indents to tabs (and using 8 space tabs on the project to
make sure the code looks the same ;-))

Im now using commit.sh, too.

I don't think a mailing list for commit notification is really
necessary, at least not for me. Concerning the ChangeLog, i don't think
i hurts to have autogenerated one, and we can still write one by hand.

now about the programm itself, i think the next changes could be adding
a menu bar at the top, and adding support for profiles.


-- 
Christian Schilling <csc...@gm...>