From owner-freebsd-x11@freebsd.org Fri May 17 10:06:12 2019 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63C591590458 for ; Fri, 17 May 2019 10:06:12 +0000 (UTC) (envelope-from freebsd-x11@dino.sk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 996446CF57 for ; Fri, 17 May 2019 10:06:11 +0000 (UTC) (envelope-from freebsd-x11@dino.sk) Received: by mailman.ysv.freebsd.org (Postfix) id 55A941590456; Fri, 17 May 2019 10:06:11 +0000 (UTC) Delivered-To: x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 316351590454 for ; Fri, 17 May 2019 10:06:11 +0000 (UTC) (envelope-from freebsd-x11@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B00976CF56 for ; Fri, 17 May 2019 10:06:10 +0000 (UTC) (envelope-from freebsd-x11@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 17 May 2019 12:06:07 +0200 id 00F40596.5CDE878F.0000A569 Date: Fri, 17 May 2019 12:06:07 +0200 From: Milan Obuch To: Niclas Zeising Cc: x11@freebsd.org Subject: Re: Nothing newer as https://wiki.freebsd.org/Graphics/Intel-GPU-Matrix? Message-ID: <20190517120607.574078bd@zeta.dino.sk> In-Reply-To: <20190517115916.0b8dbd58@zeta.dino.sk> References: <20190516110515.11afc7ad@zeta.dino.sk> <8df3c740-5a84-bd0c-7b9a-8d8d24e041c0@daemonic.se> <940088bd-a545-8b02-06c2-a6388ea6e69c@daemonic.se> <20190517113621.2762239e@zeta.dino.sk> <20190517115916.0b8dbd58@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B00976CF56 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 10:06:12 -0000 On Fri, 17 May 2019 11:59:16 +0200 Milan Obuch wrote: > On Fri, 17 May 2019 11:49:36 +0200 > Niclas Zeising wrote: >=20 > > On 2019-05-17 11:36, Milan Obuch wrote: =20 > > > On Thu, 16 May 2019 11:35:13 +0200 > > > Niclas Zeising wrote: > > > =20 > > >> On 2019-05-16 11:12, Niclas Zeising wrote: =20 > > >>> On 2019-05-16 11:05, Milan Obuch wrote: =20 > > >>>> Hi, > > >>>> > > >>>> this page is last edited end of year 2018. Is there anything > > >>>> newer? Of particular interest for me are Bay Trail CPUs I am > > >>>> trying to run X on, but no success yet. Well, vesa video works, > > >>>> kind of, but I need Full HD resolution which seems not possible > > >>>> with vesa. > > >>>> > > >>>> If anybody has something to share, maybe some work-in-progress > > >>>> for test, it would bee great... > > >>>> =20 > > >>> > > >>> Hi! > > >>> Graphics driver versions hans't been updated since the end of > > >>> 2018, so that is the newest version.=C2=A0 There is ongoing work to > > >>> update the driver to current, but that is not in base yet. > > >>> Regards =20 > > >> > > >> Hi! > > >> The bay trail SoCs could be supported from a graphics perspective > > >> even if they aren't listed. I suggest you install drm-kmod and > > >> try. You'll see if it attaches to the hardware. > > >> =20 > > >=20 > > > Hi, > > >=20 > > > so I did full reinstall with 12.0-STABLE snapshot, used port > > > drm-fbsd12.0-kmod-4.16.g20190430, kldload /boot/modules/i915kms.ko > > > and it works - kind of. Just one trouble, I can't see anything on > > > screen connected to VGA output, just mouse X cursor, because other > > > output is active before VGA and all three xterms are there, left > > > of my visible screen (I can move mouse cursor to the left, off the > > > screen). > > >=20 > > > grep EDID Xorg.0.log > > >=20 > > > [ 715.398] (II) intel(0): EDID for output eDP1 > > > [ 715.398] (II) intel(0): EDID Version: 1.4 > > > [ 715.399] (II) intel(0): EDID (in hex): > > > [ 715.427] (II) intel(0): EDID for output VGA1 > > > [ 715.428] (II) intel(0): EDID Version: 1.3 > > > [ 715.429] (II) intel(0): EDID (in hex): > > > [ 715.429] (II) intel(0): EDID for output DP1 > > > [ 715.430] (II) intel(0): EDID for output HDMI1 > > >=20 > > > So I think I need somehow disable eDP1 output and it should be OK, > > > but how? When i915kms module is kldloaded, there are some tunables > > > mentioned, like kern.vt.fb.modes.VGA-1 - could it be used for > > > it? =20 > >=20 > > Hi! > > If you have started X (which I assume you have from your > > description), try fiddling with xrandr. Just running xrandr without > > any arguments should show all screens connected to your computer. > > You can then disable certain screens with > > xrandr --output [name-of-output] --off > > The name of the output is listed in the xrandr output from the first > > run. Is this a dual or multi screen set up? > > =20 >=20 > I did, and yes, I tried already xrandr. It gives me just what I need. > My question was if it is possible to do it before starting X, but > calling xrandr from xinitrc is not a big deal for me. I just checked, > works satisfactorily. >=20 > There is one strange thing, though not X related - when i915kms module > is kldloaded, screen switched to higher resolution, but strangely, not > full screen could be used, it looks like it scrolls up in the middle > of physical screen. Any idea on this? >=20 > Regards, > Milan > Addendum: in dmesg I see following after kldload i915kms: VT: Replacing driver "efifb" with new "fb". start FB_INFO: type=3D11 height=3D768 width=3D1366 depth=3D32 cmsize=3D16 size=3D8294400 pbase=3D0xc01a0000 vbase=3D0xfffff800c01a0000 name=3Ddrmn0 flags=3D0x0 stride=3D7680 bpp=3D32 cmap[0]=3D0 cmap[1]=3D7f0000 cmap[2]=3D7f00 cmap[3]=3Dc4a000 end FB_INFO It looks like again here, some data are read from eDP1 port, at least resolution, at this is used for VGA1 port as well, albeit in this case it is wrong. So I need some kind of override here, too. Milan