On Wed, Jul 06, 2011 at 10:36:22PM +1200, Jason alavaliant wrote:
> On Wed, Jul 6, 2011 at 12:37 PM, Chris Bagwell <[email protected]> wrote:
> > I do not know the long term plan for this as well but I can make some
> > educated guesses.  It doesn't make sense to use xsetwacom for this
> > feature unless you add logic directly into xf86-input-wacom that opens
> > the sysfs file and send data itself.  If this is done then it will be
> > able to open that device for same reason it can open the root owned
> > /dev/input devices related to tablet.  That would solve your problem
> > right there.
> >
> 
> That seems a sensible way to cover it,   didn't think of it going via the
> actual X driver rather than xsetwacom accessing sysfs directly.

I suggest to add a property containing a number of Pixmaps (in the order of the 
oleds on
the device) and the Pixmaps contain the actual data. The conversion between
Pixmap to driver-specific data format is then done in the driver.
Pixmaps are just 32 bit IDs, so the property code is trivial too.

This way you get to use all client-side tools that already draw to pixmaps
(e.g. cairo) instead of having to write your own.

Cheers,
  Peter

> > From xf86-input-wacom developer viewpoint, It seems a lot of effort
> > for effectively a pass threw service.  I'd pursue something like your
> > doing first.
> >
> 
> Yes I'll not be waiting for support in xf86-input-wacom  directly,  (I'm of
> the understanding that such support is many months off and I've got working
> code that just needs to be integrated in wacom-config ready right now.)
> 
> 
> >
> > For this type of issue, people don't really change the permission of
> > these sysfs though.
> >
> > What I've recently done as a stepping stone for similar problem is to
> > create a utility that does the work of accessing the sysfs and passing
> > data to it.  Then I create a sudoer file that gives everyone access to
> > that 1 utility.  Its kinda  a strange way to work around not having
> > permission control but it does fit in nicely with way people normally
> > do this stuff.
> >
> > If you look at all the GUI's/applets that control sysfs settings, they
> > all seem to have daemons running as root to do the actual access and
> > communicate with GUI using DBUS.  The way you register your dbus
> > system service is very similar to that sudoer  file (its a security
> > policy).  Then your utility becomes a daemon and you tack on some dbus
> > glue between two programs.
> >
> > The applets that control CPU frequency in gnome seem to use PolicyKit
> > to access the sysfs but I couldn't find much info on how to do it that
> > way... and it seemed to me if you use PolicyKit you can get root
> > access but you'll always get a popup window asking for a password for
> > this access.  Not something you want to occur at each login.  Maybe
> > there is a way to configure that access without popup window?
> >
> > Hope its of some help,
> > Chris
> >
> 
> 
> Yes that very helpful thanks,  I didn't think of PolicyKit for some reason
> but it's certainly worth looking into it.    Depending on what capabilities
> are available with reference to sysfs it might cover grant accesses to
> normal users (some of my coworkers have used it to great success for
> transparently enabling networking type permissions for limited accounts)
> possibly with the need for a password prompt.
> 
> I think dbus and daemons are more work than I want to put into this (plus I
> don't trust my code not to make any root daemon a massive security hole)
> As a more basic step while integrating the code I've got I think I'll also
> look at setting up wacom-config so that if the users running it doesn't have
> permissions it will optionally try running
> some sort of limited sudo command that just copies the images.   I bit
> clunkier than I'd like but should allow things to work at a very basic
> level.
> 
> -J

> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2

> _______________________________________________
> Linuxwacom-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to