FreeBSD-12.1 on laptop

Scott Bennett bennett at sdf.org
Fri Nov 29 06:37:01 UTC 2019


     First off, knock it off, you guys who have been leading "vm finance" down
the primrose path for *days*.  It is not amusing. ~>:-E

vm finance <vm.finance2 at gmail.com> wrote:

> Please find error output of startx....and kldstat output as well.

vm finance,
     As I've followed your postings and others' responses, several things have
become apparent.  For one, you appear not to know the difference between an
ordinary port and a metaport.  An ordinary port builds and installs software.
A metaport installs *nothing* at all, except for an entry in the pkg data base
that claims that the metaport is "installed".  Metaports have other purposes,
e.g., math/octave-forge, which installs nothing, but an attempt to install it
gets you a menu from which you can choose which special octave libraries/tools
developed at sourceforge out of dozens available in the ports tree you would
like to have installed.  It then adds those selected from the menu to its own
dependency lists, thereby forcing those other ports/packages to be installed.
     graphics/drm-kmod is a metaport, and it does not install software.  It
chooses the appropriate drm kernel module's port for your system based upon
the version of your system and adds that port to its own dependency list, thus
forcing that specific drm kernel module to be built and installed.
     When you did a "pkg delete drm-kmod", all you did was remove the entry
for the metaport from the pkg data base of installed ports/packages.  You did
not remove any software.  The drm.ko module that you had originally installed
from pkg was the one built for the 12.0-RELEASE GENERIC kernel.  AFAICT from
all that you have posted to the list(s) to date, you have never removed or
replaced that module.  Each time you think you are installing or updating
graphics/drm-kmod, all you are doing is installing or updating the pkg data
base entry for the metaport.  The metaport sees that graphics/drm-fbsd12.0-kmod
is already installed, so it finds no further work to do.  What you need to do
now is something like "portmaster graphics/drm-fbsd12.0-kmod" *or* if you don't
have portmaster installed (see ports-mgmt/portmaster),

cd /usr/ports/graphics/drm-fbsd12.0-kmod
make deinstall && make && make install

Either method should rebuild the port based upon your currently installed
system and then install it for you.  Note that there is *still* no port called
drm-fbsd12.1-kmod (nor is there a drm-fbsd11.3-kmod), so drm-fbsd12.0-kmod is
indeed the one you need, but it must be built for the system it runs on.
>
> Thanks everyone for your support and help!

     Please continue reading, and also please stop top-posting.  It is quite
rude, and my usual treatment of top-posted text appearing below the signature
block is simply to delete it because the previous poster to whom I am replying
obviously considered it irrelevant.  In this case I am making an exception due
to the seemingly egregious treatment you've gotten on this list.
>
> On Thu, Nov 28, 2019 at 6:16 PM Daniele Mazzotti <kappei84 at gmail.com> wrote:
>
> > Can you grep for Kms in the boot modules? Also as suggested in the link
> > sent by Per is your user part of the video group? If not please just add
> > it. When you compiled the drm-kms port have you noticed any error?
> >
> > Il gio 28 nov 2019, 13:08 vm finance <vm.finance2 at gmail.com> ha scritto:
> >
> >> I don't see /boot/modules/i915kms.ko under /boot/modules
> >> However there are several other present:
> >> i915_bxt_*
> >> i915_cnl*
> >> i915_kbl*...
> >>
> >> How do I get i915kms.ko?
> >>
> >> Thanks!
> >>
> >> On Thu, Nov 28, 2019 at 5:01 PM Per Hedeland <per at hedeland.org> wrote:
> >>
> >> > On 2019-11-28 11:03, vm finance wrote:
> >> > > Hi,
> >> > >
> >> > > Its Intel's "UHD Graphics 620". I don't see it installed/loaded under
> >> > > "kldstat".
> >> > >
> >> > > Do you think steps mentioned in
> >> > > http://www.srobb.net/freebsdintel.html
> >> > >
> >> > > would suffice to get around the issue I have?
> >> > > If not, could u please suggest next steps.
> >> > >
> >> > > Pls let me know. Thanks so much!
> >> >
> >> > Sigh, after all the discussion and problem / fix reports (mostly on
> >> > the freebsd-x11@ list, which I'm adding to Cc) about the "new DRM"
> >> > stuff, one would think that there should be some simple-to-follow
> >> > *FreeBSD* web page that explained it all and could be pointed to if
> >> > not immediately found.
> >> >
> >> > There is https://wiki.freebsd.org/Graphics, which IMHO is neither
> >> > simple to find nor to follow, and which still has the broken-with-12.1
> >> > "pkg install drm-kmod" advice. I think it is sad, since there's a lot
> >> > of great work that has gone into this - personally I have a laptop
> >> > that wouldn't have had *any* graphics (on FreeBSD) without it, and I
> >> > know I'm not alone in that.

     The reason for the above is one of those artifacts of cute and expedient
ideas with poorly thought out consequences that become clearly visible in
hindsight.  As the various drm kernel module versions for different FreeBSD
versions were being turned into ports, there were large numbers of bugs reported
in bugzilla and on the -x11@ mailing list.  Those early ports did not have names
reflecting the OS versions to which they were applicable, and in some cases more
than one choice was available for a particular OS version.  When the graphics
team eventually considered them ready for general use, the names were changed
to drm-{legacy,fbsd1{1.2,2.0},current,devel}-kmod.  The drm-kmod metaport selects
*only* either drm-fbsd11.2-kmod or drm-fbsd12.0-kmod for its dependency list.
People choosing any of the other versions are expected to understand what they
are doing already and know enough to install their desired version directly with
no metaport involved.
     The problem appears when someone who has not been following developments on
the -x11@ list wants to install a drm driver, follows some instruction to "install"
drm-kmod, and does *not* understand what that really means, which implies that user
will not understand what has gone wrong when he tries to "update/upgrade" drm-kmod
(i.e., precisely nothing).  Developers keep track of what is going on from the
cutting edge to the legacy support.  Ordinary users rarely do.  The metaport, on
balance, was not a good idea.  Instead, the graphics team should have gotten its
port names straightened out and then written good instructions regarding which
ports to install onto which OS versions and for which graphics hardware.  The
metaport is useful only once per combination of user, hardware, and OS version.
Beyond that point, it should be ignored or removed.  The same information could
better have been supplied in the FreeBSD Handbook and each drm port's pkg-descr
file.
> >> >
> >> > Anyway, enough ranting - if you look at the "Intel Integrated Graphics
> >> > (aka HD Graphics)" section on the above page, and specifically the
> >> > "Example Configuration For Post Broadwell System", and *skip* the bad
> >> > pkg advice, you'll find that the next step is to add
> >> >
> >> >      kld_list="/boot/modules/i915kms.ko"
> >> >
> >> > to rc.conf - and actually the "post-install package message" will have
> >> > told you so, but yeah, who reads those things...

[snort]  Only those who care, I imagine. :-)
> >> >
> >> > The problem (not explained anywhere that I can find right now) is that
> >> > after building and installing the drm-kmod port (or package), you have
> >> > *two* drivers called i915kms installed. One is part of the base
> >> > system, /boot/kernel/i915kms.ko - this is the one that doesn't work
> >> > for you (or me), and gets loaded if you do "kldload i915kms". The

     Yeah, don't do that.  It may load the wrong one.  It may also not work
if one by the same name has already been loaded.

> >> > other is from the port that you installed, and it's the above
> >> > /boot/modules/i915kms.ko - you must ensure that this is the one that
> >> > is loaded.
> >> >
> >> > The above line makes sure that this happens at reboot (loading via
> >> > boot/loader.conf has been reported to *not* work in at least *some*
> >> > cases, and there's no advantage over loading via /etc/rc.conf), but
> >> > you can also do it manually for testing, by using the full path with
> >> > "kldload":
> >> >
> >> >    kldload /boot/modules/i915kms.ko
> >> >
     Right, but check first to be sure that one is not already loaded and in
use.

> >> > Read and follow also the subsequent steps in the example, as well as
> >> > the "Note:" at the end of the section. If your card is actually
> >> > supported (and frankly I'm not sure how to figure that out in any
> >> > other way than trying it), you should be fine at that point.
> >> >
> >> > --Per Hedeland
> >> >
      One last thing I should point out is that "vm finance" posted a list of
his already loaded kernel modules.  Polytropon then made some annotations to
the list, happily proclaiming that the desired drm module was already loaded,
the which statement was false.  The drm2.ko module he highlit was the one
from /boot/kernel/, not the drm.ko installed by the drm-fbsd12.0-kmod port
into /boot/modules/.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************


More information about the freebsd-questions mailing list