Peter Hutterer wrote: > On Wed, Oct 08, 2008 at 11:05:07PM +0200, Simon Thum wrote: > So your point is to never have properties in the driver that could be in the > server? This may be tough, as drivers have a quicker turnover time, and > features can get added easier. Well, against double-handling a prop in general. Uh, I didn't even rant about order dependencies which may sneak in.
Alternative (assuming only-one-handler): Should anyone 'capture' an existing prop we could add some controlled pass-through behaviour, e.g. by starting the handler list from the current (or any specified) handler on. > I agree with the example being of questionable use. However, as we just > started with the whole thing I don't think we can quite grasp what the next > few months may bring in terms of property support. And I wouldn't be surprised > if a use-case pops up where we need that. I hope you don't mind me digging out some old saying from the forfathers: 'Don't try to fix a problem you don't have'. > One other example I came up with while writing the email: some property > that needs handling in the DIX and one of the DDXes. This would require two > separate handlers, the code can't be merged into one. Well, yes. But IMO that smells too. > If the state is changed through changing the property - easy. Otherwise, the > code must ensure that XIChangeDeviceProperty() is called. Then you really should be looking at VTSwitch or power mgmt. That part is clear, but it's so easy to circumvent unexpectedly. But I don't know anything reliable either. > which case we get an error value. And I hope that any property is reasonably > documented so that one knows what values are legit :) Do you intend to have some point to collect related info? E.g. wiki? It could help a lot to easily see what types there are, how others did etc. > Sure, it may get complicated if we have 10 handlers for each property. But at > that point we should got back to the drawing board and see what we have done > wrong. Because I don't think that merging the code from 10 different handlers > into one handler would be any more straightforward. Sorry, but I can't help regarding that as an argument against multiple handlers per prop - but anyway. Cheers, Simon _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
