Re: [PATCH 0/3] X Input 1.5 device properties (final patches)
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)
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)
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)
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)
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)
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)
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)
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
