empty CD not correctly recognized by hal

Bug #66254 reported by manuel on 2006-10-15
90
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HAL
Fix Released
Medium
hal (Ubuntu)
Undecided
Martin Pitt

Bug Description

Binary package hint: nautilus-cd-burner

Nautilus does not recognize new cds. I've loaded one but it continue asking for a new one.

I was enable to burn at command line

$ mkisofs -R . | cdrecord -v fs=6m speed=2 dev=/dev/hdb -

$ cat /etc/issue
Ubuntu edgy (development branch) \n \l

Desired=Unknown/Install/Remove/Purge/Hold
| Estado=No/Instalado/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: mayúsc.=malo)
||/ Nombre Versión Descripción
+++-==================-===============-============================================
ii nautilus 2.16.1-0ubuntu2 file manager and graphical shell for GNOME
ii nautilus-cd-burner 2.16.1-0ubuntu1 CD Burning front-end for Nautilus
ii nautilus-data 2.16.1-0ubuntu2 data files for nautilus
ii nautilus-sendto 0.7-2ubuntu6 integrates Evolution and Gaim into the Nauti
ii cdrecord 2.01+01a03-5ubuntu2 command line CD writing tool
ii libnautilus-burn4 2.16.1-0ubuntu1 Nautilus Burn Library - runtime version
ii nautilus-cd-burner 2.16.1-0ubuntu1 CD Burning front-end for Nautilus

$ lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 740 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS961 [MuTIOL Media IO]
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter

$ uname -a
Linux jms-desktop 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux

Related branches

manuel (manuel-soto) wrote :

I don't know if there is a security problem.

Nautilus does not let to duplicate CDs, I have to install k3b but umount /media/cdrom manually in order to let it duplicate. K3b fail unmounting device.

Note: only one cdrom

Later,
Manuel S

Sebastien Bacher (seb128) wrote :

Thanks for your bug. Could you run /usr/lib/nautilus-cd-burner/list_cddrives and get a lshal log and attach them to the bug?

Changed in nautilus-cd-burner:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
manuel (manuel-soto) wrote :

/usr/lib/nautilus-cd-burner/list_cddrives

manuel (manuel-soto) wrote :

lshal

Sebastien Bacher (seb128) wrote :

thank you. Are those with an empty CD to the drive?

manuel (manuel-soto) wrote :

previous posting was w/a non empty cd on the drive.

New attachments has other combinations

manuel (manuel-soto) wrote :
manuel (manuel-soto) wrote :
Sebastien Bacher (seb128) wrote :

hal also shows the lack of informations on the media:

"...
  info.udi = '/org/freedesktop/Hal/devices/volume_empty_unknown' (string)
  volume.disc.is_rewritable = false (bool)
  volume.disc.is_appendable = false (bool)
  volume.disc.is_blank = true (bool)
  volume.disc.has_data = false (bool)
  volume.disc.has_audio = false (bool)
  volume.disc.type = 'unknown' (string)
..."

reassigning

Changed in nautilus-cd-burner:
assignee: desktop-bugs → nobody
status: Needs Info → Confirmed
Thibaut Cao (cao-swing) wrote :

I have the same problem here using a LG_CD_RW_CED_8120B

 WARNING **: No property volume.disc.capacity on device with id /org/freedesktop/Hal/devices/volume_empty_unknown

when using nautilus-cd-burner or Brasero.

It simply asks to add a support and refuses any CDR. This is very annoying as I'm not able to write any CD usings these softwares.

Thibaut Cao (cao-swing) wrote :

I still have this problem with the new feisty beta. Is someone working to find out the problem or is there a hope for a solution?

sharpkiddie (mark-eurogamer) wrote :

I also have exactly the same problem with a 'SAMSUNG_CDRW/DVD_SM_308B'. My IDE controller is a '82801BA IDE U100' according to device manager, if this is of relevance. I tried a second drive earlier and this also failed in what seemed to be an identical manner, however I no longer have access to this drive to get any more information about it.

Thorsten (ungesaeuertesbrot) wrote :

I believe 69033 and 72654 are duplicates of this one. Don't know if I'm entitled to simply mark them as such though...

John Williams (jswillms) wrote :

I will confirm that this problem is still happening on the RC version of Feisty. Can pull logs, etc if needed... using cdrecord worked just fine so no hdwe issue.

John Williams (jswillms) wrote :

I think this may be due to buggy cd rom firmware, if my rusty code reading skills are still valid. In probe_volume.c, it appears that the ioctl data back from the driver is bogus for blank media. For sure, the disc.type field is being marked as unknown. If I put in a non-blank disk, I get valid sizes. A blank disk gives bad info... Only way that probe_volume.c gets this is from the ioctl.

So, my opinion is that this is a driver problem, not a hal bug.

My drive is an old IDE CD_ROM Writer. cdrom links to sr_mod.

Could this perhaps be related to the ide to sata changes of late? Probably still a firmware bug...

John Williams (jswillms) wrote :

BTW, This drive is a CDWriter IDE 8432. This was a fairly common drive. Bet that most of these type reports are due to the various rebadged drives of this type. This one was made by BTC for CDWriter, I think. Best to defer this bug and recommend that they upgrade to newer hdwe. No firmware avail for this old of a drive.

sharpkiddie (mark-eurogamer) wrote :

Please don't be so hasty to write this one off and advise users to upgrade: the drive I'm having problems with is in a relative's 6/7 year old Dell, so probably not an uncommon piece of kit (and certainly not that old). How come cdrecord functions fine with the drive if there is some fundamental firmware issue with size reporting? Please forgive my ignorance here :)

Any idea how I can find out if a SAMSUNG_CDRW/DVD_SM_308B == CDWriter IDE 8432? I can't get physical access to the drive right now since it's about 100 miles away!

The drive I am using is a External SCSI HP 9600 (from dup bug 69033). It is only 5 years old. I would prefer that this bug was investigated (and hopefully fixed) rather than deffered.

John Williams (jswillms) wrote :

Both good points. Here is my view/opinion on how to proceed. BTW, this will have to be fixed upstream in Gnome...

First, cdrecord probably does not check the capacity prior to recording, and will fail if the eventutal amount of data to be copied to the drive exceeds the capacity of the cd.

So, it appears that we have an issue with older drives that cannot accurately predict the size of an unformatted media. It could be a mini-disk of 200meg or so, a 650 meg disc or 700 meg disk. Newer drives probably have a better shot at predicting the size of the media.

My recommendation is to change the way that CD-Creator prompts for the message. If the drive says it is blank but the size is 0 or very small, say that they are unable to determine the capacity of the media, do you want to proceed? If the drive is blank and the capacity is non-zero, proceed as is now done. i.e. make it a soft error, not a hard one.

Thorsten (ungesaeuertesbrot) wrote :

Well it seems that my drive (which is affected - see dup #72654) does report the correct size which is 359849 sectors (with 2048 Bytes in each sector that makes about 700MB), at least according to cdrecord dev=/dev/hdd -atip. Unfortunately it does report a wrong start sector (i.e. start of lead in at -11607 and start of track 1 at -150) though, which might be causing the problem. Anyway to me this seems to be indicating that we are facing a hal bug and not a gnome bug here. Correct me if I'm wrong though.

John Williams (jswillms) wrote :

Thorsten, does cdrecord work properly? In my case, cdrecord works but CD-Creator does not.

My read of the hal code is that it is at the mercy of the drive firmware (or device driver). It performs no added value other than issueing the ioctl and mapping the content appropriately.

DarkMageZ (darkmagez) wrote :

oddly enough. this used to work fine in edgy & dapper.

Thorsten (ungesaeuertesbrot) wrote :

Yes, cdrecord does work properly (it says something like "drive reports wrong startsec of -150 for track 1. assuming startsec 0" though). neither nautilus-cd-burner nor brasero work though. Last time it worked was on dapper.
btw i tries writing an fdi script to change the values in hal. This made the popup asking what to do next (ignore, burn data cd, burn music cd) appear again (which it didn't) but didn't fix the problem of nautilus-cd-burner asking for an empty disc once i hit the burn button.

Thorsten (ungesaeuertesbrot) wrote :

the attatched file goes into /etc/hal/fdi/information. This fixes the problem for me but might not fix it for everyone. The script simply changes anything that is a volume with a parent that can burn cd-rs and that has an unknown type and is blank into a cd-r with 700MB. This is certainly not a real solution to the problem but might be a start. for example it doesn't work with cd-rws and dvds.

John Williams (jswillms) wrote :

In thinking about this some more, I am wondering if this problem is related to the change from PATA to SATA drivers in 2.6.20. I wonder if the old IDE driver has some special code to handle older drives that gave bogus data. That is the only reason I can think of to be causing this sort of problem between edgy and Feisty....

Thibaut Cao (cao-swing) wrote :

No it isn't. I have the problem since edgy. Maybe the backend for nautilus cd-burner changed then to make use of HAL.

Marshall Scorcio (marshalium) wrote :

Is their anyone still working on this bug or anyone who has found a workaround?

I am affected by it and it is the only thing keeping me from upgrading my dapper installation to feisty.

If there is anything I can do to help get this fixed let me know.

a workaround would be to use cdrecord

Jerome Potts (jerome-potts) wrote :

My workaround was to use X-CD-Roast instead, but the drive recently failed on me, cdrecord had quit working too. So i replaced the cheap 2001 HP 'R/RW 8x4x32' with a 2002 'CDWRITER IDE2410' and that solved the pbm for me. But yes, with the old drive before its failure, X-CD-Roast wasn't giving me as much grief as the Gnome Desktop integrated thing.

Thorsten (ungesaeuertesbrot) wrote :

The file I tried to attach above is a perfect workaround as long as you only use media of one type and size. The upload was broken though, so I'll attach it again here.
As I said above it goes to /etc/hal/fdi/information.

Thorsten (ungesaeuertesbrot) wrote :

Well, I don't know why, but launchpad won't allow me to attach that file. So here are its contents:

-----cut-----
<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
 <device>

  <match <email address hidden>:storage.cdrom.cdr" bool="true">
  <match key="block.is_volume" bool="true">
   <match key="volume.disc.type" string="unknown">
    <match key="volume.disc.is_blank" bool="true">
     <merge key="volume.disc.type" type="string">cd_r</merge>
     <merge key="volume.disc.capacity" type="uint64">736970752</merge>
    </match>
   </match>
  </match>
  </match>
 </device>
</deviceinfo>
-----cut-----

experimenting with the values I set here (in the merge elements) or other values in hal might enable you to use discs of different types or sizes.

Marshall Scorcio (marshalium) wrote :

Thorsten Schoel,

Thank you for the workaround it works perfectly.

Madmoose (desaad) wrote :

Hello,

Ubuntu Edgy: 6.10

Serpentine 0.7 doesn't see blank disks for me too.

If you need more info just drop me an email.

Madmoose (desaad) wrote :
Sika (sikamikaniboots) wrote :

I have the same problem.
My burner is a LG CED 8080B.
I've tried to create the .fdi file of Thorsten Schoel but it simply don't work (volume.disc.type and volume.disc.capacity are not changed).
I've tried to use cdrecord and it seems to work.
If you need some infos just ask.

Sika (sikamikaniboots) wrote :

Here is a full hal debug output (as described on the second half of https://wiki.ubuntu.com/DebuggingRemovableDevices).

Thorsten (ungesaeuertesbrot) wrote :

Hello Sika,
the .fdi won't work with the new hal from feisty-backports since that version doesn't support the uint64 data type anymore for whatever reason. If you have the feisty-backports channel active downgrading hal to the feisty version will likely do the job.

Sika (sikamikaniboots) wrote :

Thanks a lot Thorsten !
Now I can burn cds with nautilus.
The last problem is that brasero still says "no disc" when I insert a blank cd. Maybe it's a brasero bug ?

Ulrich Büchsel (buechsel) wrote :

Hello!

I have the same problem with my Lite-on LTR-12101B CD burner since the upgrade from ubuntu 6.06 to 6.10.

Interestingly hal under 6.06 didn't recognize inserted media either. So my first supposition was that a change in the code of nautilus-cd-burner was responsible for the error. I found out that nautilus-cd-burner under 6.06 contained a non-hal-fallback-code which missed under 6.10 and 7.04. I compared the source code of hal and nautilus-cd-burner (6.06) which detects the disc type of the inserted media which gave me a hint how a possible solution of this problem might work:

Under nautilus-cd-burner (ubuntu 6.06) I found the function nautilus_burn_drive_get_medi_type_from_path_full which calls the subfuction get_mmc_profile which can be found in the source code file dvd_plus_rw_utils.c up from line 159. As far as I understand the code an the comments this function at first calls a certain SCSI function which is called GET CONFIGURATION. The comments say that "some older drives support MMC-1 but don't support the GET CONFIGURATION command (which is part of the MMC-2 spec)". Therefore there is a fallback routine up from line 240 which tries to determine the disc type from the information if the disc is blank and/or erasable. The comment says: "if the profile has not yet been set, we're dealing with an older CD-R or CD-RW burner (which doesn't know the GET CONFIGURATION command. Do some digging into the disc type to figure out what's in the drive".

In the hal code (version 0.5.8.1) the source code file hald/linux/probing/probe_volume.c seems to be interesting. In "main" it calls the function get_disc_type to determine the disc type. This function is coded in the file hald/linux/probing/linux_dvd_rw_utils.c up from line 743. In this function apparantly only the SCSI function GET CONFIGURATION is called. It doesn't seem to contain any code for older cd drives which do not support this command. For me this seems to be the probable reason why hal cannot detect the disc type in my cd burner. My burner is quite old (about 6 or 7 years).

So my idea is to incorporate the fallback code of nautilus-cd-burner into hal. Perhaps this would solve the problem. Has anyone in this forum contact to the hal developers and could suggest this to them?

Ulrich Büchsel (buechsel) wrote :

Hello!

I tried to apply the suggested changes to the source code of hal, but even before this I didn't manage to compile hal. It always ends up with an error message like this:

/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/libpci.a(names.o): In function `pci_load_name_list':
(.text+0x538): undefined reference to `gzopen'

I have installed the package zlib1g-dev.

So I will attach the changes I have applied to the file hald/linux/probing/linux_dvd_rw_utils.c in the function get_disc_type. Perhaps anyone else will succeed in applying these changes and compiling hal.

Ulrich Büchsel (buechsel) wrote :
David C (da-cas) wrote :

Mmm, interesting, I realise others are stumbling around the same problem as I have, though I had made my comments on https://bugs.launchpad.net/bugs/109763.
As the HAL specification says that volume.disc.capacity is not mandatory, I guess HAL developers may not accept the idea of including the code. I tried nautilus-cd-burner-2.14.3 successfully and it contains the alternative code, so I will stick with that for the time being, but clearly there are a number of people suffering because of this. Hope a fix can be sorted soon.

David C (da-cas) wrote :

I did it myself.
I have made a patch to HAL that might fix this problem for you.

Ulrich Büchsel (buechsel) wrote :

Thank you David. Your patch worked for me too. My own patches posted on 2007-07-07 and 2007-07-08 don't work. I'm still trying to make them work.

Unfortunately ubuntu update notifier constantly suggests to replace the patched version with a more recent version because I applied the patch to version 0.5.8.1 of hal.

I saw that you tried to draw the hal developers' attention to the bug and your patch on the hal mailing list and I am astonished that neither the hal nor the ubuntu developers seem to take notice of it.

Glad to hear it works. Can you let us know what your CD drive is. There is a list of CDs for which the fix is reported good in the last 4 messages on https://bugs.launchpad.net/ubuntu/+source/hal/+bug/109763.

I patched 0.5.9 because, before working on the patch, I got the most recent HAL in case others had fixed the problem. The patch works just fine for both cases, so you might just have to use the latest sources and re-apply to avoid the irritating update messages until a patch is adopted by Canonical.

Perhaps you (and others subscribing to either 66254 or 109763 (the same problem, just expressed slightly differently)) contact the HAL developers directly with your observations (and I'm CC'ing the Debian maintainer on this).

The problem has only recently started to appear because until around a year ago (specifically N-C-B 2.14.3, last
date in the sources of which is 31/07/06) contained code that probed the disc directly when HAL failed to return the MMC value.

Debian Testing uses
2.18.2, from 29/05/07, so developers/distributors have not actually had very long to
discover that there are quite a number of folk out there with old CD
drives that used to work and that will no longer do so.

My patch to HAL was just a slight re-coding of the code from N-C-B 2.14.3, and I did that rather than simply patching N-C-B because it seemed a cleaner place to make the mod: e.g. the 'Hardware Information' Browser now reports the empty CD size, and that would not have worked unless the change were made in HAL.

Regards

David

> From: <email address hidden>
> To: <email address hidden>
> Date: Sat, 1 Sep 2007 14:06:54 +0000
> Subject: [Bug 66254] Re: empty CD not correctly recognized by hal
>
> Thank you David. Your patch worked for me too. My own patches posted on
> 2007-07-07 and 2007-07-08 don't work. I'm still trying to make them
> work.
>
> Unfortunately ubuntu update notifier constantly suggests to replace the
> patched version with a more recent version because I applied the patch
> to version 0.5.8.1 of hal.
>
> I saw that you tried to draw the hal developers' attention to the bug
> and your patch on the hal mailing list and I am astonished that neither
> the hal nor the ubuntu developers seem to take notice of it.
>
> --
> empty CD not correctly recognized by hal
> https://bugs.launchpad.net/bugs/66254
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com

Hi,
it seems that for some drives the disc capacity of blank discs can't be properly determined, yielding in a "no empty disc inserted" error in nautilus-cd-burner and brasero for example.

** (brasero:1359): WARNING **: No property volume.disc.capacity on device with id /org/freedesktop/Hal/devices/volume_empty_unknown

There's an Ubuntu bug about this here:
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/109763

Which includes a patch that seems to work fine:
http://launchpadlibrarian.net/8641782/68-disc_identification.patch

Would be nice to have this included in hal soonish :)

Bye

This is btw with hal 0.5.9.1 on Ubuntu (0.5.9.1-6ubuntu5), i.e. with a bunch of patches. None of those should affect this bug though...

(Seems to work of course means that it works fine for me)

(Patch is not by me but by David Castelow as can be seen in the Ubuntu bugreport)

Alberto Piai (alberto-piai) wrote :

Hi all,

I'm having the same problem with Gutsy on a Macbook.
HAL doesn't seem to recognize blank CDs and DVDs.
Used to work just fine with Feisty, though.

Inspected the log output of udev, gnome-volume-manager and hald, as in https://wiki.ubuntu.com/DebuggingRemovableDevices, but none of them shows any reaction when a blank cd/dvd is inserted.

Any hints?

Thanks,

Alberto

David C (da-cas) wrote :

This does not look like the problem I addressed with my patch, as it is unllkely your CD drive is not MMC-2, and the problem would have showed up in Feisty. Not sure the wiki is quite appropriate, but certainly check HAL output: as well as using HALD in debug mode you can use the HAL device manager (System->Preferences->Hardware Information): if it sees a CD it will show as a "child" of the CD drive named "Unknown Device", but from your description perhaps even this is not happening. Can GUTSY see your CD drive at all?

Alberto Piai (alberto-piai) wrote :

I run hald from a shell, as

$ sudo hald --daemon=no --verbose=yes 2>&1 | tee hal.log

I confirm, when i insert a blank disk no debug output is shown, just no reaction at all.

In hal-device-manager the cd drive is listed as a scsi device, DVDRW GWA4080MA. All the properties like store.cdrom.cdr, cdrw, dvdplusr, etc. are correctly set to "true". But no, with a disk inserted there's no child of the cd drive.

CDs with data and video dvds work just fine.

Does anyone else with a Macbook have the same issue? It is from April 2007, with a Core 2 Duo.

Thanks,

Alberto

DarkMageZ (darkmagez) wrote :

alberto... this bug report is not related to your problem and should only be used for things that are related to this bug. please use the answers section to seek help or file your own bug report.

David C (da-cas) wrote :

Alberto: just seen that someone has filed a bug report that sounds like it might be your issue: Bug #158033.

Commited the patch

Changed in hal:
status: Confirmed → Triaged
Martin Pitt (pitti) wrote :

This patch is included in my currently prepared Hardy hal upload. You can already test it now by installing the packages in my PPA: https://launchpad.net/~pitti/+archive

Changed in hal:
assignee: nobody → pitti
status: Triaged → Fix Committed
Changed in hal:
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (6.2 KiB)

This bug was fixed in the package hal - 0.5.10+git20080301-1ubuntu1

---------------
hal (0.5.10+git20080301-1ubuntu1) hardy; urgency=low

  * Merge with Debian to pull in a current snapshot from upstream git head
    (upstream neglects doing a long-overdue 0.5.11 release). This pulls in two
    tons of bug fixes and reduces our insane stack of patches to a
    maintainable level again. (LP: #198295)
    - Uses MMC profile reading for CDs/DVDs. (LP: #66254)
  * Remove the following patches which are upstream now:
    - 01_proc_sys_batteries.patch
    - 02_sysfs_battery_serial.patch
    - 92_gxx43.patch
    - 94_batter-model_name.patch
    - 97_fix_power_info_via_sysfs.patch
  * Drop 80_allow_vfat_usefree.patch; Using 'usefree' VFAT mount option is not
    necessary with the current Hardy kernel any more.
  * Drop debian/patches/82_ignore_fixed_nonmedia.patch: Obsolete, GVFS treats
    fixed partitions correctly.
  * Tag and forward the subset of our remaining patches which have some kind
    of documentation and justification. Rename them to clean up patch order
    prefixes a bit.
  * 96_uinput_device_support.patch: Adapt to new upstream version.
  * Remaining Ubuntu changes:
   - debian/hal.init: Remove stray gparted-disable-automount.fdi on startup.
     Needs to be kept until Gnome #324220 is fixed properly.
     (LP #134712)
   - debian/hal.init: Unconditionally chown the directory in the init script.
     (LP #175525)
   - Ubuntu udev world order:
     + debian/hal.links: Remove rules symlink, we install the rules file
       directly into rules/.
     + debian/rules: Install udev rules into /etc/udev/rules.d/.
     + debian/hal.{preinst,postinst,postrm}: Transition code for changing the
       udev rule priority (see 0.5.8.1-3ubuntu7, needs to be kept until after
       Hardy's release).
   - debian/hal.preinst, debian/libhal1.preinst: Clean up doc directory
     symlinking when upgrading from Gutsy. Needs to be kept until after
     Hardy's release.
   - debian/rules: Enable MacBook (Pro) support on i386 and amd64. Add
     pciutils-dev build dependency.
   - debian/rules: Do not run stop init.d script for levels 1 and 6
     (TearDown).
   - debian/preferences.fdi: Disable automounting for fixed disks. On session
     startup it is not done anyway (since that disables the gnome-mount UI
     which would ask for authentication) and it leads to confusion when
     restarting hal while a session is running. (LP #138537)
   - Various bug fixes, see their patch headers:
     + 02_allow_ufs_ufstype.patch
     + 03_virtual_net_devices.patch
     + 04_read_brightness_not_actual_brightness.patch
     + 96_uinput_device_support.patch
     + ubuntu_01_ignore_single_slash_label.patch
   - 83_ssb_bus_support.patch: Add support for devices on the SSB bus; patch
     by Matthew Garrett (not applied upstream yet, this needs to update the
     spec, too).
   - 84_memstick_bus_support.patch: Add support for devices on the "memstick"
     bus; patch by Matthew Garrett (not reported upstream yet, this needs to
     update the spec, too).
   - 88_change_pm_quirk_policy.patch: Patch by Matthew Garret, undocumented,
     non-obvious purpose.
   - Use Polic...

Read more...

Changed in hal:
status: Fix Committed → Fix Released
Changed in hal:
importance: Unknown → Medium
Changed in hal:
importance: Medium → Unknown
Changed in hal:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.