Alternative approach to MT_TOOL_ENVELOPE
Quoted 9 lines
Quoted 4 lines
Ping has touched upon this subject as well, from the pen & touch perspective. Generally, some ABS axes are actually enumerations, for which we have no direct abstraction. If we had a way to declare the used values for such enumerations, it would resolve these and possibly other issues.
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?
Yes. Having something like INPUT_QUIRK_SEMI_MT might be enough, and we could drop the whole MT_TOOL_ENVELOPE circus. Chase, Peter, Chris, would you be comfortable with such a solution?
Quoted 2 lines
Anyway, it looks like we have a few concerns with current
MT_TOOL_ENVELOPEso I want to rewind my 'next' branch.
Yep. Should I also take the opportunity to sync from -rc1 instead, and fold the cleanup patches into the appropriate places?
Thanks,
Henrik
Quoted 5 lines · Henrik Rydberg
Quoted 4 lines
Quoted 4 lines
Ping has touched upon this subject as well, from the pen & touch perspective. Generally, some ABS axes are actually enumerations, for which we have no direct abstraction. If we had a way to declare the used values for such enumerations, it would resolve these and possibly other issues.
Quoted 8 lines
Quoted 4 lines
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?Yes. Having something like
INPUT_QUIRK_SEMI_MTmight be enough, and we could drop the wholeMT_TOOL_ENVELOPEcircus. Chase, Peter, Chris, would you be comfortable with such a solution?
That sounds like a good solution to me. I believe it would resolve all the issues I had.
As I attempted to write up more documentation, I thought of the following. What do you think?
With regards to partial MT devices, if the device provides a single valued property, such as pressure and tool type for synaptics, it may only be provided through the traditional property semantics, i.e. ABS_PRESSURE and BTN_TOOL_*. If the device provides multiple values for a property, then ABS_MT_* types may be used as well to provide up to two values, though the client should understand there's no direct correlation between the slot's coordinates and the property. I could see this being used to provide info on multiple tool types or a high and low pressure.
Enforcing the above behaviour provides even more information about the capabilities of the device based solely on the evdev codes published.
Thanks,
-- Chase
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?
Quoted 6 lines
Quoted 3 lines
Yes. Having something like
INPUT_QUIRK_SEMI_MTmight be enough, and we could drop the wholeMT_TOOL_ENVELOPEcircus. Chase, Peter, Chris, would you be comfortable with such a solution?That sounds like a good solution to me. I believe it would resolve all the issues I had.
Sounds good.
Quoted 13 lines
As I attempted to write up more documentation, I thought of the following. What do you think?
With regards to partial MT devices, if the device provides a single valued property, such as pressure and tool type for synaptics, it may only be provided through the traditional property semantics, i.e.
ABS_PRESSUREand BTN_TOOL_*. If the device provides multiple values for a property, then ABS_MT_* types may be used as well to provide up to two values, though the client should understand there's no direct correlation between the slot's coordinates and the property. I could see this being used to provide info on multiple tool types or a high and low pressure.
Quoted 2 lines
Enforcing the above behaviour provides even more information about the capabilities of the device based solely on the evdev codes published.
Looks good, but I do not think we need to formalize all possibilities here, only the usage of MT data for bounding rectangle and ST data for finger count. Referring to the patch just sent: whenever INPUT_PROP_SEMI_MT is true, this behavior is expected. In the event of new odd hardware, the combination of a new property quirk and a documented recipe should do the trick.
Thanks,
Henrik
Quoted 34 lines · Henrik Rydberg
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?Quoted 6 lines
Quoted 3 lines
Yes. Having something like
INPUT_QUIRK_SEMI_MTmight be enough, and we could drop the wholeMT_TOOL_ENVELOPEcircus. Chase, Peter, Chris, would you be comfortable with such a solution?That sounds like a good solution to me. I believe it would resolve all the issues I had.
Sounds good.
Quoted 13 lines
As I attempted to write up more documentation, I thought of the following. What do you think?
With regards to partial MT devices, if the device provides a single valued property, such as pressure and tool type for synaptics, it may only be provided through the traditional property semantics, i.e.
ABS_PRESSUREand BTN_TOOL_*. If the device provides multiple values for a property, then ABS_MT_* types may be used as well to provide up to two values, though the client should understand there's no direct correlation between the slot's coordinates and the property. I could see this being used to provide info on multiple tool types or a high and low pressure.Quoted 2 lines
Enforcing the above behaviour provides even more information about the capabilities of the device based solely on the evdev codes published.
Quoted 5 lines
Looks good, but I do not think we need to formalize all possibilities here, only the usage of MT data for bounding rectangle and ST data for finger count. Referring to the patch just sent: whenever
INPUT_PROP_SEMI_MTis true, this behavior is expected. In the event of new odd hardware, the combination of a new property quirk and a documented recipe should do the trick.
Would you feel comfortable stating the above in less concrete terms, as sort of a best practices guide? I'd like to know for this specific case if you agree beyond ST finger count data, or if you feel we should do something else like always provide as much data as possible in MT properties? It's a real corner case, and I don't care too much one way or another. I just don't want synaptics implemented one way, elantech another, etc.
Thanks,
-- Chase
Quoted 22 lines
Quoted 16 lines
Quoted 12 lines
With regards to partial MT devices, if the device provides a single valued property, such as pressure and tool type for synaptics, it may only be provided through the traditional property semantics, i.e.
ABS_PRESSUREand BTN_TOOL_*. If the device provides multiple values for a property, then ABS_MT_* types may be used as well to provide up to two values, though the client should understand there's no direct correlation between the slot's coordinates and the property. I could see this being used to provide info on multiple tool types or a high and low pressure.Quoted 2 lines
Enforcing the above behaviour provides even more information about the capabilities of the device based solely on the evdev codes published.
Quoted 5 lines
Looks good, but I do not think we need to formalize all possibilities here, only the usage of MT data for bounding rectangle and ST data for finger count. Referring to the patch just sent: whenever
INPUT_PROP_SEMI_MTis true, this behavior is expected. In the event of new odd hardware, the combination of a new property quirk and a documented recipe should do the trick.
Quoted 7 lines
Would you feel comfortable stating the above in less concrete terms, as sort of a best practices guide? I'd like to know for this specific case if you agree beyond ST finger count data, or if you feel we should do something else like always provide as much data as possible in MT properties? It's a real corner case, and I don't care too much one way or another. I just don't want synaptics implemented one way, elantech another, etc.
A driver can still choose to report ABS_MT_PRESSURE for instance, in which case it is assumed to make sense for individual fingers/corners. For semi-mt devices, it seems reasonable to go to the ST variants to collect information not provided via the MT protocol. I see no immediate reason to specify beyond that point.
Thanks,
Henrik
Quoted 11 lines · Chase Douglas
Quoted 10 lines · Henrik Rydberg
Quoted 9 lines
Quoted 4 lines
Ping has touched upon this subject as well, from the pen & touch perspective. Generally, some ABS axes are actually enumerations, for which we have no direct abstraction. If we had a way to declare the used values for such enumerations, it would resolve these and possibly other issues.
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?
Quoted 6 lines
Quoted 3 lines
Yes. Having something like
INPUT_QUIRK_SEMI_MTmight be enough, and we could drop the wholeMT_TOOL_ENVELOPEcircus. Chase, Peter, Chris, would you be comfortable with such a solution?That sounds like a good solution to me. I believe it would resolve all the issues I had.
Works for me as well.
Quoted 14 lines
As I attempted to write up more documentation, I thought of the following. What do you think?
With regards to partial MT devices, if the device provides a single valued property, such as pressure and tool type for synaptics, it may only be provided through the traditional property semantics, i.e.
ABS_PRESSUREand BTN_TOOL_*. If the device provides multiple values for a property, then ABS_MT_* types may be used as well to provide up to two values, though the client should understand there's no direct correlation between the slot's coordinates and the property. I could see this being used to provide info on multiple tool types or a high and low pressure.
Quoted 3 lines
Enforcing the above behaviour provides even more information about the capabilities of the device based solely on the evdev codes published.
I meant to mention: once your initial draft gets committed I would love to help update it some. I specifically want to show two example usage. 1) touchpad as 1 to 3 touchs occur and show special considerations to ABS_* that apps should handle. 2) a touchscreen that supports a pen as well and show how tool change (finger to pen) should work. For both those examples, it would be interesting to discuss how MT can be used concurrently (does pen in slot 0 and touch in slot 1 make sense for example).
I think it will be invaluable to document this stuff for driver writers and apps but I'm not sure yet what level needs to be enforced.
Chris
Quoted 8 lines · Chris Bagwell
I meant to mention: once your initial draft gets committed I would love to help update it some. I specifically want to show two example usage. 1) touchpad as 1 to 3 touchs occur and show special considerations to ABS_* that apps should handle. 2) a touchscreen that supports a pen as well and show how tool change (finger to pen) should work. For both those examples, it would be interesting to discuss how MT can be used concurrently (does pen in slot 0 and touch in slot 1 make sense for example).
This is the other main reason I wanted to make the document. Having a place where best practices are detailed will help future driver writers and hopefully reduce errors in evdev code usage. I'd love to see this added to the document.
I do think that MT is complex enough that related documentation should be in multi-touch-protocol.txt, though. Anywhere I discussed MT in evdev-codes.txt I referred the reader to the other file. Henrik, does that sound good to you?
Quoted 2 lines
I think it will be invaluable to document this stuff for driver writers and apps but I'm not sure yet what level needs to be enforced.
That's the biggest issue I see right now. Do we want black and white specificity? For example, using terms like "must" and "may not" etc. Or do we want the document to merely hold best practices while not proscribing exact details? I think even with exact details we can loosen them if needed, but that has its own can of worms.
Dmitry, what are your thoughts on this?
Thanks,
-- Chase
Quoted 6 lines
I do think that MT is complex enough that related documentation should be in multi-touch-protocol.txt, though. Anywhere I discussed MT in evdev-codes.txt I referred the reader to the other file. Henrik, does that sound good to you?
Yep, thanks.
Quoted 8 lines
Quoted 2 lines
I think it will be invaluable to document this stuff for driver writers and apps but I'm not sure yet what level needs to be enforced.
That's the biggest issue I see right now. Do we want black and white specificity? For example, using terms like "must" and "may not" etc. Or do we want the document to merely hold best practices while not proscribing exact details? I think even with exact details we can loosen them if needed, but that has its own can of worms.
It will most likely need to be judged on a case-by-case basis.
Thanks,
Henrik
Quoted 5 lines · Henrik Rydberg
Quoted 4 lines
Quoted 4 lines
Ping has touched upon this subject as well, from the pen & touch perspective. Generally, some ABS axes are actually enumerations, for which we have no direct abstraction. If we had a way to declare the used values for such enumerations, it would resolve these and possibly other issues.
Quoted 8 lines
Quoted 4 lines
I think that presence of pen/touch can be detected by having
BTN_TOOL_PENandBTN_TOOL_FINGER. However in this case the tool is finger, so I do not think we should introduceBTN_TOOL_ENVELOPE. Maybe this is another case where we should employ the proposed device flags?Yes. Having something like
INPUT_QUIRK_SEMI_MTmight be enough, and we could drop the wholeMT_TOOL_ENVELOPEcircus. Chase, Peter, Chris, would you be comfortable with such a solution?
sounds good to me, thanks.
Cheers,
Peter
Quoted 9 lines
Quoted 2 lines
Anyway, it looks like we have a few concerns with current
MT_TOOL_ENVELOPEso I want to rewind my 'next' branch.Yep. Should I also take the opportunity to sync from -rc1 instead, and fold the cleanup patches into the appropriate places?
Thanks,
Henrik