Possible to add dbus integration?

Bug #364856 reported by Vadim Peretokin
Affects Status Importance Assigned to Milestone

Bug Description

Is it possible to have Disper send display change signals via dbus and have the current mode / setting the current monitor mode available?

Revision history for this message
wvengen (wvengen) wrote :

Thanks for your feature request, I think it could be done. Could you please describe your inteded use?

Revision history for this message
Vadim Peretokin (vperetokin) wrote : Re: [Bug 364856] Re: Possible to add dbus integration?

see disper-applet branch in disper ;)

Revision history for this message
wvengen (wvengen) wrote :

Obviously I missed something, this is great!

So you're writing an applet that allows the user to change multi-display configuration, nice. It certainly is useful to update the applet status when the configuration is changed otherwise. Still, I'm not sure a dbus client is the full solution, since other programs like nvidia-settings and even hardware hotkeys can change the state as well. The NVidia API has a way to subscribe to display configuration changes which should catch all. I think it would be better to use this method, and I can look into adding it to disper (not sure how tough it is without creating a C module for Python...)
And you might want to use disper's Switcher class anyway instead of calling it from the command-line, since it provides easy access to the display information. Switcher is a backend-independent api that should provide an abstraction for different video cards (NVidia is fully implemented, XRandR partly, ATI not at all, at this moment). I'm open to reworking Switcher if required.
Food for discussion :)

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Yes. I think it would make more sense though to have the dbus functionality in disper, such that not everyone will need the applet to be notified and etc (someone for example might want to do a KDE widget).

I've also subscribed Eugene now, forgot to do that the first time. Oops.

Revision history for this message
wvengen (wvengen) wrote :

Well, I agree that the applet should be able to know easily about display configuration changes. I don't think, however, that adding dbus functionality in disper is the whole story. Please let me explain.

Currently disper is running as a short-lived process to perform a single display configuration change. As such it could emit a (dbus) event when it does so, no problem. But still there may be other display configuration changes that are not caught, like:
 * nvidia-settings and other programs using the NV-CONTROL extension directly
 * XRandR mode switches for metamodes that have been defined
 * hardware hotkeys
 * possibly the kernel module in some cases (I don't know)
I think it is essential to catch these changes as well. These events can only caught using the NV-CONTROL extension (using XNVCtrlSelectTargetNotify and friends if I am correct).

So someone has to listen for these events. This could be the disper utility that would run as daemon and post events on dbus, or this could in the application itself (using disper as a library). Running as a daemon cannot (easily) be done as root since it needs the user's display socket (although it would be better to implement it on a system level but alas no sourcecode), so it should either be run as part of the session, or the application that needs disper's dbus events could run disper on demand when not present. This would ideally be implemented in the disper library so applications don't need to duplicate that code.

And so there hardly is any difference for an application developer in using dbus messages and the disper api, at least not for python applications. Disper needs to have this event api anyway to implement a dbus daemon, so I'd like to suggest to
  1) add an api to disper to receive display configuration changes
  2) use the api in the applet
  3) ... if there is need again for a dbus daemon, implement that

(as a side note: maybe the X server should listen for nvidia events and post them to the dbus, since that's the hardware plumbing layer. But until then, we'll continue this work :) )

I look forward to your response.

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Unfortunately that's a bit outside of the scope of the project as time for now is limited, sorry :(

I think the applet for now will be just made to set the status and now to be able to tell it via different icons and radio button selection.

I will look though into having disper re-packaged such that it installs the API files in a location the applet can find and use them directly.

Revision history for this message
wvengen (wvengen) wrote :

Thanks for your reply. I agree that it is quite some work, and I'll put it on my todo list for disper (by means of this bug). My time is limited currently but I'll try to look into it; adding status update for your applet would not be too complicated when that is finished, I would think.

Of course you can just add ${PREFIX}/share/disper/src to your python lib path for now, but it may indeed be a good idea to install the api at the python package location. Let's discuss that in a different bug.

Changed in disper:
assignee: nobody → wvengen
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
wvengen (wvengen) wrote :

If anyone knows of existing dbus messages for communicating display configuration changes, please add that information here.

Revision history for this message
wvengen (wvengen) wrote :

With the plugin system of disper 0.3.0 it should be possible to implement this separately. Please look at the notify plugin for an example, which sends a system notification upon mode switch.

Changed in disper:
assignee: wvengen (wvengen) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers