[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade



On Tue, May 15, 2012 at 09:32:14AM +0200, Michel Dänzer wrote:
> In order to alleviate the problem, I made the X driver bail.
> 
> I just don't think it's worth it for a corner case caused by broken
> configuration.

But if you can guess the parameters of the problem, why not tell the user
in the error message to check those parameters, rather than have an error
message that talks of something seemingly different and misleads them.
Simply integrate the existing C comment into the message. For example:

        /* Looks like we're trying to start in UMS mode on a KMS kernel.
         * This can happen if the radeon kernel module wasn't loaded before
         * X starts.
         */
        xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
            "[dri] RADEONDRIGetVersion failed because of a version mismatch.\n"
            "[dri] In the UMS code path, this chipset requires a kernel module version\n"
            "[dri] of %d.%d.%d, but the kernel reports a version of %d.%d.%d.\n",
            info->dri->pKernelDRMVersion->version_major,
            info->dri->pKernelDRMVersion->version_minor,
            info->dri->pKernelDRMVersion->version_patchlevel);
        if (info->dri->pKernelDRMVersion->version_major > 1) /* or something? */
          xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
            "[dri] If you actually want to use KMS rather than UMS, make sure the radeon\n"
            "[dri] kernel module is loaded prior to starting X (make sure it's not blacklisted),\n"
	    "[dri] and that this driver was built with support for KMS.\n"
            "[dri] Aborting.\n");

When we know that we have users who didn't cause this to themselves through
a PEBCAK, rather, other packages caused it and then left their conffiles to
persist with the damage even after the user did everything ages ago, we
shouldn't dismiss those user complaints.

Heck, in this kind of a case where the potential for breakage is high,
I don't think anyone would actually mind if the package also declared:

Conflicts: fglrx-driver
Breaks: fglrx-driver

and did this in its postinst script:

if test -f /etc/modprobe.d/fglrx-driver && 
  grep -q ^blacklist\ radeon /etc/modprobe.d/fglrx-driver; then
  mv /etc/modprobe.d/fglrx-driver /etc/modprobe.d/fglrx-driver.breaks.radeon;
  display critical priority debconf message saying run modprobe radeon
  or reboot before (re)starting the X server again, or else
fi

-- 
     2. That which causes joy or happiness.



Reply to: