Rémi Bernon rbernon@codeweavers.com writes:
On 4/27/21 4:55 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
On 4/27/21 4:26 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
In the end, having the default implementation run all the time didn't seem too bad, especially if as it's not doing much, and if we consider it could then be extended to cover more cases and reduce the amount of driver code.
If we consider keyboard layouts I would think that it could be decided based on the HKL, with some special value(s) meaning the layout is handled by the driver while "standard" layout would be implemented in user32.
Anyway, If you like the NTSTATUS style more, I can do it like this.
I still find it better to call the driver first, and do the extra work only if needed. If we do it right, the default implementation is only going to become more complex, and that would be all the more reason to ask the driver first. I'm not sure that I see a need to use NTSTATUS here, plus it wouldn't quite fit with the usual user32 calling conventions. At some point we may want to turn this into a syscall interface and use NTSTATUS everywhere, but that would be a complete redesign of the driver interface.
Yes, and I said NTSTATUS with that in mind, but it could very well be BOOL for now and return TRUE/FALSE if it's implemented or not, the inconvenience of changing the driver return paths is pretty much the same though.
Ok it's maybe not that bad...
I find return -2 in the null driver a lot easier, but maybe that's just me ;-)
In this case sure, but then there's things like MapVirtualKeyEx or the other calls. But maybe I'm trying too hard to have a consistent pattern for something that is subject to change anyway.
Yes, the driver interface is pretty much ad-hoc, there's no need to try hard to be consistent. In general, the idea is for the driver entry points to look as much as possible like their user32 counterparts, so in that sense a magic return value is better than extra parameters.