Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-24 Thread Simon Thum
Peter Hutterer wrote:
> In the default case (if you do not have a handler) the property will get
> deleted. Only if you want to absolutely prohibit anyone from deleting the
> prop, then you need a handler.
> 
> The reason for the decision is that if two handlers affect the same
> property, one handler may be fine with the deletion, the other one not.
Sounds fine! Seems I was a bit confused about handlers needing to agree 
on deletion: They actually may exercise a veto or not. That may be a 
clearer wording (should you do some docs).

Cheers,

Simon

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-23 Thread Peter Hutterer
On Wed, Sep 24, 2008 at 07:48:57AM +0200, Simon Thum wrote:
>> If deletable is FALSE, the prop can only be deleted by the server/a driver,
>> and even then only if all handlers agree.
> That's a bit stricter than what I was looking for. If I want to delete a  
> prop in-server, I'd like be able to avoid asking handlers (as I was  
> before). Otherwise, I'm still forced to implement a delete handler for  
> the sole purpose of giving up the veto at some time. Essentially I need  
> a parallel channel to delete my own props. Boils down to dumping

In the default case (if you do not have a handler) the property will get
deleted. Only if you want to absolutely prohibit anyone from deleting the
prop, then you need a handler.

The reason for the decision is that if two handlers affect the same
property, one handler may be fine with the deletion, the other one not.

>> -if (fromClient && device->properties.handlers)
>> +if (device->properties.handlers)
>
> that part. And maybe rename fromClient to checkHandlers or deletable to  
> clientDeletable, whatever. IOW: If deletable is FALSE and fromClient is  
> TRUE, handlers have to agree.

agreed - clientDeletable is better. I'll amend the patch.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-23 Thread Simon Thum
Peter Hutterer wrote:
> Right, I can see your point. How about the patch below (untested)? It's on top
> of the other patches and adds a DeleteProperty handler, and a deletable flag.
Looks good.

> If deletable is FALSE, the prop can only be deleted by the server/a driver,
> and even then only if all handlers agree.
That's a bit stricter than what I was looking for. If I want to delete a 
prop in-server, I'd like be able to avoid asking handlers (as I was 
before). Otherwise, I'm still forced to implement a delete handler for 
the sole purpose of giving up the veto at some time. Essentially I need 
a parallel channel to delete my own props. Boils down to dumping

> -if (fromClient && device->properties.handlers)
> +if (device->properties.handlers)

that part. And maybe rename fromClient to checkHandlers or deletable to 
clientDeletable, whatever. IOW: If deletable is FALSE and fromClient is 
TRUE, handlers have to agree.

Admittedly weaker, but maybe the more practical semantics.

Cheers,

Simon
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-23 Thread Peter Hutterer
On Tue, Sep 23, 2008 at 09:02:34PM +0200, Simon Thum wrote:
> one more thing: A Handler already consists of getter and setter, so  
> there's an incentive to abstracting 'hey thats my property' on the  
> handler side anyway. So why load deletion onto the setter as a special  
> case of modification? I think it would be cleaner to have an own  
> 'sub-handler' for deletion.
>
> Or, since 99% of in-server code will just protect its props (at least,  
> no other use case comes to my mind), we could make it a property flag  
> again. I understand you want to get rid of it, but I think this one  
> could save some code on the handlers side. Mostly code which isn't  
> exactly DRY.

Right, I can see your point. How about the patch below (untested)? It's on top
of the other patches and adds a DeleteProperty handler, and a deletable flag.

If deletable is FALSE, the prop can only be deleted by the server/a driver,
and even then only if all handlers agree.

>From aa3b6cf0bd533bc264f3acddf14222a6e04f9d44 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Wed, 24 Sep 2008 10:18:14 +0930
Subject: [PATCH] Xi: add "deletable" flag to properties, add DeleteProperty 
handler.

Deletable properties may be deleted, if the handlers allow it.

Non-deletable properties may be deleted by a driver/server if all handlers
allow it. A client cannot delete these properties.
---
 Xi/xiproperty.c|   34 ++
 dix/devices.c  |9 +++--
 include/exevents.h |   13 ++---
 include/inputstr.h |6 --
 4 files changed, 43 insertions(+), 19 deletions(-)

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 94d5499..1e4ed46 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -97,10 +97,11 @@ long
 XIRegisterPropertyHandler(DeviceIntPtr dev,
   int (*SetProperty) (DeviceIntPtr dev,
   Atom property,
-  XIPropertyValuePtr prop,
-  BOOL delete),
+  XIPropertyValuePtr prop),
   int (*GetProperty) (DeviceIntPtr dev,
-  Atom property))
+  Atom property),
+  int (*DeleteProperty) (DeviceIntPtr dev,
+ Atom property))
 {
 XIPropertyHandlerPtr new_handler;
 
@@ -111,6 +112,7 @@ XIRegisterPropertyHandler(DeviceIntPtr dev,
 new_handler->id = XIPropHandlerID++;
 new_handler->SetProperty = SetProperty;
 new_handler->GetProperty = GetProperty;
+new_handler->DeleteProperty = DeleteProperty;
 new_handler->next = dev->properties.handlers;
 dev->properties.handlers = new_handler;
 
@@ -155,6 +157,7 @@ XICreateDeviceProperty (Atom property)
 prop->value.format = 0;
 prop->value.size   = 0;
 prop->value.data   = NULL;
+prop->deletable= TRUE;
 
 return prop;
 }
@@ -220,20 +223,23 @@ XIDeleteDeviceProperty (DeviceIntPtr device, Atom 
property, Bool fromClient)
 {
 XIPropertyPtr   prop, *prev;
 devicePropertyNotifyevent;
-int rc;
+int rc = Success;
 
 for (prev = &device->properties.properties; (prop = *prev); prev = 
&(prop->next))
 if (prop->propertyName == property)
 break;
 
+if (fromClient && !prop->deletable)
+return BadAccess;
+
 /* Ask handlers if we may delete the property */
-if (fromClient && device->properties.handlers)
+if (device->properties.handlers)
 {
 XIPropertyHandlerPtr handler = device->properties.handlers;
 while(handler)
 {
-rc = handler->SetProperty(device, prop->propertyName,
-  &prop->value, TRUE);
+if (handler->DeleteProperty)
+rc = handler->DeleteProperty(device, prop->propertyName);
 if (rc != Success)
 return (rc);
 handler = handler->next;
@@ -346,7 +352,7 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 if (handler->SetProperty)
 {
 rc = handler->SetProperty(dev, prop->propertyName,
-  &new_value, FALSE);
+  &new_value);
 if (rc != Success)
 {
 if (new_value.data)
@@ -420,6 +426,18 @@ XIGetDeviceProperty (DeviceIntPtr dev, Atom property, 
XIPropertyValuePtr *value)
 }
 
 int
+XISetDevicePropertyDeletable(DeviceIntPtr dev, Atom property, Bool deletable)
+{
+XIPropertyPtr prop = XIFetchDeviceProperty(dev, property);
+
+if (!prop)
+return BadAtom;
+
+prop->deletable = deletable;
+return Success;
+}

Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-23 Thread Simon Thum
Hi Peter,

one more thing: A Handler already consists of getter and setter, so 
there's an incentive to abstracting 'hey thats my property' on the 
handler side anyway. So why load deletion onto the setter as a special 
case of modification? I think it would be cleaner to have an own 
'sub-handler' for deletion.

Or, since 99% of in-server code will just protect its props (at least, 
no other use case comes to my mind), we could make it a property flag 
again. I understand you want to get rid of it, but I think this one 
could save some code on the handlers side. Mostly code which isn't 
exactly DRY.

I don't advocate exporting the flag to everywhere, just keep it 
internally as a cheap[0] way to protect your properties from 
hostile/faulty clients.

Cheers,

Simon

[0] Measured in LoC
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-23 Thread Peter Hutterer
One more patch that was missing from the previous patchset.

New file include/xserver-properties.h that includes #defines for the
properties managed by the server.

File is installed as part of the SDK to be included by clients who wish to
manipulate said properties.

This way we don't have to bump inputproto for new properties (e.g. ptr accel
configuration, a "driver" property, etc.)

Cheers,
  Peter


>From 826b6441fe27304a37c0452457ff6c7ba952bfff Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 16:55:04 +0930
Subject: [PATCH] Push server-known properties into xserver-properties.h.

---
 Xi/xiproperty.c  |1 +
 dix/devices.c|1 +
 include/Makefile.am  |3 ++-
 include/xserver-properties.h |   32 
 4 files changed, 36 insertions(+), 1 deletions(-)
 create mode 100644 include/xserver-properties.h

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 50a4caf..94d5499 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -38,6 +38,7 @@
 #include "swaprep.h"
 
 #include "xiproperty.h"
+#include "xserver-properties.h"
 
 /**
  * Properties used or alloced from inside the server.
diff --git a/dix/devices.c b/dix/devices.c
index c0ff019..a16cd1c 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -86,6 +86,7 @@ SOFTWARE.
 #include "exevents.h"
 #include "listdev.h" /* for CopySwapXXXClass */
 #include "xiproperty.h"
+#include "xserver-properties.h"
 
 /** @file
  * This file handles input device-related stuff.
diff --git a/include/Makefile.am b/include/Makefile.am
index 76c265e..f639048 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -53,7 +53,8 @@ sdk_HEADERS = \
windowstr.h \
xkbfile.h   \
xkbsrv.h\
-   xkbstr.h
+   xkbstr.h\
+   xserver-properties.h
 
 nodist_sdk_HEADERS = xorg-server.h
 endif
diff --git a/include/xserver-properties.h b/include/xserver-properties.h
new file mode 100644
index 000..4d602b5
--- /dev/null
+++ b/include/xserver-properties.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright 2008 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software")
+ * to deal in the software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * them Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER
+ * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+
+/* Properties managed by the server. */
+
+#ifndef _XSERVER_PROPERTIES_H_
+#define _XSERVER_PROPERTIES_H_
+
+/* BOOL. 0 - device disabled, 1 - device enabled */
+#define XI_PROP_ENABLED  "Device Enabled"
+
+#endif
-- 
1.5.4.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-22 Thread Adam Jackson
On Mon, 2008-09-22 at 18:08 +0930, Peter Hutterer wrote:
> Here's the (hopefully) final patches to device properties in the server.
> As mentioned in [1], Configure/Query property functionality and requests have
> been culled.
> 
> Patch 1 removes these requests. An updated inputproto is required as well of
> course.
> Patch 2 allows property handlers to return status codes instead of just
> TRUE/FALSE. These status codes (if != Success) are returned to the client
> as errors.
> Patch 3 asks handlers before the deletion of a property. This allows a handler
> to implement immutable properties.

From a quick read these look good.  ACK.

- ajax


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 0/3] X Input 1.5 device properties (final patches)

2008-09-22 Thread Peter Hutterer
Here's the (hopefully) final patches to device properties in the server.
As mentioned in [1], Configure/Query property functionality and requests have
been culled.

Patch 1 removes these requests. An updated inputproto is required as well of
course.
Patch 2 allows property handlers to return status codes instead of just
TRUE/FALSE. These status codes (if != Success) are returned to the client
as errors.
Patch 3 asks handlers before the deletion of a property. This allows a handler
to implement immutable properties.

Updated inputproto and evdev patches that conform to this implementation are
waiting and can be pushed. Documentation update is nearly there and will be
pushed with the pack.

Cheers,
  Peter

[1] http://lists.freedesktop.org/archives/xorg/2008-September/038262.html



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg