session bus is the wrongplace for this as the xserver runs outside the session (as root) normally. it is part of the infra to HOST a session, but not quite part of it (one example would be x spawned by lightdm/xdm).
so in the generic sense, this is kind of "wrong".
i'm kind of surprised that you used dbus protocol? i might have gone by
creating an x extension and then it's be directly tied to the display
itself (as you connect to it). like a wm or compositor - you conenct and
then set debug up and get debug events like x events etc. as it's x11
specific this would have been my go. give xcb protocol files and xcb
extension code generation, this should have not been hard. but too late
now.
On 11/04/2014 05:05 PM, Boram Park wrote:
> Hi
>
> On 11/04/2014 02:49 AM, St챕phane Desneux wrote:
>> Hi Boram,
>>
>> Could you, please, elaborate a little bit on the problem you're facing.
> During developing our project, we(samsung) faced many issues which
> were difficult to be analyzed in application side. So to analyze them
> in xserver side powerfully and conveniently, we have developed
> xf86-module-xdbg. xf86-module-xdbg consists of two parts. One is the
> module(libxdbg.so) which is loaded during xserver is launching, and혻
> another is a executable command(xdbg) which communicates with the
> module(libxdbg.so) by using DBUS system bus. By using xdbg with root
> right, we can trace x request, event, reply and error between xserver
> and xclients.
>
> However, when I tried to launch another second xserver, xdbg module
> got failure when calling dbus_bus_get because xdbg uses one request
> name(connection name?), previous xserver use .
>
> To solve this issue, looks like xdbg needs to use different request
> names for each xserver.
> - name like xxxx.xdbg-{display number}
>
> But if request name isn't fixed, I can't use bus configuration file in
> /etc/dbus-1/system.d/. (I'm not expert. If wrong, correct me. :) )
>
> So I was thinking about session bus.
>
>> Technically, as long as Xorg is launched inside a user session it will
>> have the DBUS_SESSION_BUS_ADDRESS set by systemd, as explained Maciej
>> previously.
>>
>> NB: for weston, if weston-launch is used, it's not true as weston-launch
>> clears the environment before forking weston and thus doesn't propagate
>> the DBUS_SESSION_BUS_ADDRESS. My patch would also handle this corner
>> case; but it wasn't its main goal...
>>
>> Well, this leaves me with 2 questions, regarding a multiuser system:
>>
>> * why would we want to start xorg in a user session ? There's often only
>> one GPU and the users must be able to share it :)
> As my understanding, we can launch xserver more than one ideally. One
> of the ways launching Xorg is that user can call xorg-launch-helper in
> user session. And xorg-launch-helper starts Xorg with root right. So
> above issue can be potential problem.
>
>> * if it was started as a system component, why does Xorg would need to
>> know the DBUS session address (of a particular user) ? 'app' is dead, so
>> which user are we talking about ? I hope it's not 'guest' :)
> For these reason, I was trying to use session bus in xserver side.
>> If you look at Tizen:Common/wayland images, you'll see that weston is
>> started as a system daemon and by no way it's aware of DBUS session
>> address(es). If we must make it aware of the user sessions, it could be
>> interfaced with logind (or tlm, or whatever handles the user
>> sessions)...
> I'll trying to other way not using session bus and your recommend also.
>
> Thanks
>>
>> Best regards,
>
> _______________________________________________
> Dev mailing list
> [email protected]
> https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
