ArduPilot
XSD: Remove display attribute from fields
This removes the XSD to allow display="bitmask" on a field. We now expect the bitmask attribute to be set on the enum itself.
The trigger for this was the accidental reintroduction of the attribute in https://github.com/mavlink/mavlink/pull/2289/
My concern about this is that it might break other systems that aren't directly managed by MAVLink org.
@peterbarker This works upstream, but we need get rid of the last instances here.
But, the question stands, what about other dialects that don't talk to this project?
@peterbarker This is failing because the pymavlink repo still has a version of common that includes display="bitmap" in fields. These were purged upstream. I thought had been removed in ardupilot/mavlink. IFF that's the case, I think ArduPilot/pymavlink needs to update from ArduPilot/mavlink - right?
On Tue, 30 Sep 2025, Hamish Willee wrote:
@peterbarker This is failing because the pymavlink repo still has a version of common that includes display="bitmap" in fields. These were purged upstream. I thought had been removed in ardupilot/mavlink. IFF that's the case, I think ArduPilot/pymavlink needs to update from ArduPilot/mavlink - right?
pymavlink doesn't reference mavlink. It's actually the other way around...
Perhaps a pymavlink release is required to fix the problem - where's your pymavlink coming from?
On Tue, 30 Sep 2025, Hamish Willee wrote: @peterbarker This is failing because the pymavlink repo still has a version of common that includes display="bitmap" in fields. These were purged upstream. I thought had been removed in ardupilot/mavlink. IFF that's the case, I think ArduPilot/pymavlink needs to update from ArduPilot/mavlink - right?
pymavlink doesn't reference mavlink. It's actually the other way around... Perhaps a pymavlink release is required to fix the problem - where's your pymavlink coming from?
I'm not sure what you mean. This repo is failing its tests. If it's taking mavlink/mavlink then it shouldn't.
Can you confirm that it is taking the latest mavlink/mavlink - if so then yes, it is my problem to fix. Sorry!
I'm not sure what you mean. This repo is failing its tests. If it's taking mavlink/mavlink then it shouldn't.
.... so that's pretty clear.... do we need to pull patches back into ardupilot/mavlink to fix these attributes? Do we have a PR?
Notionally we could check against both repositories.
Notionally we could check against both repositories.
I thought we'd fixed all these in ardupilot/mavlink. Perhaps some crept in. We'll need a new PR I guess.