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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Newer Lenovos apparently have a lower case "extra buttons" module, cover this
as well.
Sent by Quentin Denis <quentin.denis@gmail.com> via private mail.
This patch adds a case handling path_id invoked on a virtio-blk device.
Currently path_id walks the parent path to virtio-pci but doesn't know
that it's the end of the path and exits without building the path (providing no
output resulting in no disk/by-path symlinks to virtio-blk devices).
This patch handles the virtio-pci path and updates the path accordingly.
/lib/udev/path_id --debug /block/vda
udev_device_new_from_syspath: device 0x2300120 has devpath '/devices/virtio-pci/virtio1/block/vda'
udev_device_new_from_syspath: device 0x2300380 has devpath '/devices/virtio-pci/virtio1'
udev_device_new_from_syspath: device 0x2300670 has devpath '/devices/virtio-pci'
ID_PATH=virtio-pci-virtio1
And with the current persistent-storage rules generates:
% ls -al /dev/disk/by-path | grep vda
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-pci-virtio1 -> ../../vda
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
commit 2599cabd36770785a13bf884049d649d385fd80c
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri Jun 18 02:08:48 2010 +0300
Add autodetection for xD/smartmedia cards
This can easily be extended for other types of FTL
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Add gudev-1.0.vapi. This is based on the output of
vapigen --library gudev-1.0 GUdev-1.0.gir
with fixes to array/list semantics and include file names.
Commit 2b463cb0 changed the rules to match against hiddev* for all devices in
an attempt to fix Debian #567237/LP #444420. However, this caused regressions
with other devices (e. g. LP #550288) and thus was reverted in commit 8b56ba.
Now use hidraw* for the devices where it's confirmed that they only work with
that, and hiddev* for the others.
https://launchpad.net/bugs/444420
This fixes wlan key on Inspirion 1010 & 1110.
This patch depends on previous patches sent.
The issue with all of these is that they were all Dell mini & it wasn't
noticed till recent that they all did not follow the standard that the
rest of Dell machines follow.
Also to note while this fixes the wlan key sending the proper key press,
work is still needed at the kernel level for complete support.
This is the last patch all the Dell minis have been verified to all have
this issue, and are now covered.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
This fixed wlan key on Inspirion 1210 machines.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Pegatron has a new platform coming out being sold by many small
manufacturers. This platform has volume keys that are not sending a key
release. This patch ensures those keys send release.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Many laptop models need the same volume-key release quirk. Currently, two
models have identical force-release-maps/ keymap files (dell-studio-1557 and
fujitsu-amilo-si1848) and two more need to be added (Mitac and Coolbox QBook).
This replaces the identical force-release-maps files with one
'common-volume-keys' file to make adding new models easier.
There is no obvious DMI commonality between the models needing the quirk (i.e.
they do not all share the same BIOS), so it will remain necessary to scan for
each model separately in 95-keyboard-force-release.rules.
https://launchpad.net/bugs/565459
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
On Sat, Apr 17, 2010 at 18:26, Mike Brudevold <mike@brudevold.com> wrote:
> My CD-RW drive experiences a problem in that it automatically closes
> after opening if there is media in the drive. This only happens if
> there was media in the drive when it was last closed (an empty drive
> stays open).
...
> cd_profiles: current profile 0x02
> cd_profiles: profile 0x02 <ignored>
...
Do not pretend to have a media, when we receive a profile like 0x02,
which just means "Removable disk".
Thanks to Mike Brudevold for the initial patch.
Blank CDs do not have a TOC, thus will fail cd_media_toc() (at least with the
"Do not ignore errors from scsi_cmd_run()" fix). Thus probe the media state
first, so that we can properly detect blank media.
scsi_cmd_run() can return positive error messages if we have CHECK_CONDITION
set and get the error code from the SCSI command result. So check the result
for non-zero, not for being negative.
This should fix another cause for "phantom" media in empty CD-ROM drives.
Thanks to Mike Brudevold <mike@brudevold.com> for spotting this!
https://launchpad.net/bugs/562978
Commit 5c6954f is actually a no-op, since static variables are already zero'ed
by default anyway (but we keep it for clarity). The real difference was that a
build with -O0 wor while a build with -O2 didn't.
Turns out that some ioctls do not actually touch the result buffer in some
cases, so we need to zero the result buffers to avoid interpreting random da as
CD properties.
https://launchpad.net/bugs/559723https://launchpad.net/bugs/561585
In cases where cdrom_id does not go through the entire code path and one of the
probing functions returns -1 or exits early, the remaining variables were never
initialized. This caused effects like "phantom" audio CDs on empty drives, or
bogus data like ID_CDROM_MEDIA_TRACK_COUNT=22528.
Initialize the variables right away to avoid that.
Bug-Ubuntu: https://launchpad.net/bugs/559723
We might fight about the device with polling processes, or other
users who probe the device. Retry a few times if the other one goes
away in the meantime.
Based on a patch from Harald Hoyer.
