IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
The GP-electronic T701 has its LCD panel mounted upside-down, initially
my plan was to fix this by transparently rotating the image in the i915
driver (my "drm/i915: Deal with upside-down mounted LCD" patch), but
that approach has been rejected instead the kernel will now export
a "panel orientation" property on the drm-connector for the panel and
let userspace deal with it.
Since the upside-down-ness of the panel is now no longer transparently
hidden from userspace, the current accel mount quirk for the T701 needs
to be updated to take the upside-down-ness into account.
The input_id builtin assigns the various ID_INPUT based on the exported evdev
bits. In some cases, the device may not have the properties required to label
a device as one specific type but the physical form factor is clear.
e.g. in the case of #7197 it's a tablet pad that does not have x/y axes which
the kernel exports for pads for historical reasons.
A custom override is needed, best to be solved with a hwdb entry.
Related #7197
On some devices the display (LCD panel) is mounted non upright
in the device's casing, e.g. mounted upside-down or 90 degree rotated.
Document the expected ACCEL_MOUNT_MATRIX settings for such devices.
The vast majority of touchpads are internal, so let's assume that any USB
touchpad is internal by default (exception: bluetooth) and manually mark the
ones that are external. That's a lot more future-proof than having to mark all
internal touchpads that use USB as internal - that number is only going to
increase.
Related to #7068
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
Ignoring duplicate entry: 0001C8 = "THOMAS CONRAD CORP.", "CONRAD CORP."
Ignoring duplicate entry: 080030 = "NETWORK RESEARCH CORPORATION", "ROYAL MELBOURNE INST OF TECH"
Ignoring duplicate entry: 080030 = "NETWORK RESEARCH CORPORATION", "CERN"
→ we have two vendor prefixes with duplicate entries. For the first one,
there are two entries with what appear to be the same company. In the
second case, the same prefix is assigned to three different entities.
I arbitrarily chose to prefer the first entry.
This is rather slow (1 m 45 s on my laptop), but since it'd be only used
once per release, maybe this doesn't matter that much.
Output is identical to ids-update.pl with the set of source files committed in
the grandparent.
Without the original files it's hard to see what changed "upstream", and what
entries were added and removed. Upstream did not keep the entries sorted, and
our processing scripts did not sort the output either, so from just looking at
diffs it's hard to say what changed. So let's keep the original data, at least
for a few update cycles, so get a better handle on the upstream changes.
It's a few hundred kilobytes, so not that big, and text, so it should
compresses well.
ninja -c build hwdb-update
During the initial meson conversion, custom_target:s and run_target:s behaved
the same, and the target name became a top-level command. Now custom_target:s
require the subdir to be included, e.g. we have man/man target to build man pages,
but run_target:s not. So I think this target got a name that is so generic because
of the confusion caused by changing rules. Let's rename it.
