Re: inteldrm: always use probed screen size for fb
On Fri, 27 Jul 2018 at 19:44:28 +0200, Mark Kettenis wrote:
> > Date: Thu, 26 Jul 2018 17:56:03 -0500
> > From: joshua stein
> >
> > On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote:
> > > I'm hesitant to change this code. How does Linux behave on tese
> > > machines? Does it use the invisible part of the framebuffer? Or have
> > > they done away with actually using the kernel framebuffer completely
> > > like some developers threatened a couple of years ago...
> >
> > I booted a Linux USB drive and it just shows a purple/black screen
> > for a few seconds while the kernel loads until some text flashes for
> > half a second (systemd?) and then X loads. When I switch back to
> > the console, it doesn't draw off the screen. I have no idea what
> > it's doing under the hood to figure out the resolution for the
> > console.
>
> All the information about the size of the connected displays is there.
> But it is unclear to me how that information is propagated to the
> Linux kernel framebuffer code.
>
> Anyway, here is an alternative diff. This keeps the BIOS framebuffer
> but only uses the area that corresponds to the size we want. Keeping
> the BIOS framebuffer has some benefits. On many systems that
> framebuffer lives in "stolen" memory that we can't really use for any
> other purpose because the BIOS owns it. Also keeping the BIOS
> framebuffer would avoid a mode switch (at least in theory) and speed
> up the boot processes.
Works For Me (tm)
> Index: dev/pci/drm/i915/intel_fbdev.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 intel_fbdev.c
> --- dev/pci/drm/i915/intel_fbdev.c1 Jul 2017 16:14:10 - 1.3
> +++ dev/pci/drm/i915/intel_fbdev.c27 Jul 2018 17:26:33 -
> @@ -220,8 +220,10 @@ static int intelfb_create(struct drm_fb_
> } else {
> DRM_DEBUG_KMS("re-using BIOS fb\n");
> prealloc = true;
> +#ifdef __linux__
> sizes->fb_width = intel_fb->base.width;
> sizes->fb_height = intel_fb->base.height;
> +#endif
> }
>
> obj = intel_fb->obj;
>
Re: inteldrm: always use probed screen size for fb
> Date: Thu, 26 Jul 2018 17:56:03 -0500
> From: joshua stein
>
> On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote:
> > I'm hesitant to change this code. How does Linux behave on tese
> > machines? Does it use the invisible part of the framebuffer? Or have
> > they done away with actually using the kernel framebuffer completely
> > like some developers threatened a couple of years ago...
>
> I booted a Linux USB drive and it just shows a purple/black screen
> for a few seconds while the kernel loads until some text flashes for
> half a second (systemd?) and then X loads. When I switch back to
> the console, it doesn't draw off the screen. I have no idea what
> it's doing under the hood to figure out the resolution for the
> console.
All the information about the size of the connected displays is there.
But it is unclear to me how that information is propagated to the
Linux kernel framebuffer code.
Anyway, here is an alternative diff. This keeps the BIOS framebuffer
but only uses the area that corresponds to the size we want. Keeping
the BIOS framebuffer has some benefits. On many systems that
framebuffer lives in "stolen" memory that we can't really use for any
other purpose because the BIOS owns it. Also keeping the BIOS
framebuffer would avoid a mode switch (at least in theory) and speed
up the boot processes.
Index: dev/pci/drm/i915/intel_fbdev.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
retrieving revision 1.3
diff -u -p -r1.3 intel_fbdev.c
--- dev/pci/drm/i915/intel_fbdev.c 1 Jul 2017 16:14:10 - 1.3
+++ dev/pci/drm/i915/intel_fbdev.c 27 Jul 2018 17:26:33 -
@@ -220,8 +220,10 @@ static int intelfb_create(struct drm_fb_
} else {
DRM_DEBUG_KMS("re-using BIOS fb\n");
prealloc = true;
+#ifdef __linux__
sizes->fb_width = intel_fb->base.width;
sizes->fb_height = intel_fb->base.height;
+#endif
}
obj = intel_fb->obj;
Re: inteldrm: always use probed screen size for fb
On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote: > I'm hesitant to change this code. How does Linux behave on tese > machines? Does it use the invisible part of the framebuffer? Or have > they done away with actually using the kernel framebuffer completely > like some developers threatened a couple of years ago... I booted a Linux USB drive and it just shows a purple/black screen for a few seconds while the kernel loads until some text flashes for half a second (systemd?) and then X loads. When I switch back to the console, it doesn't draw off the screen. I have no idea what it's doing under the hood to figure out the resolution for the console. (I'd make a joke about Linux developers hiding all of that ugly kernel text output from users, but ironically the OpenBSD kernel wastes about 5-8 seconds during boot just printing kernel text through rasops.) > Do you have a (larger) monitor connected to your laptops when this happens? No, nothing connected. BTW this diff is in snaps.
Re: inteldrm: always use probed screen size for fb
> Date: Mon, 23 Jul 2018 13:28:40 -0500
> From: joshua stein
>
> On the 2015 MacBook Pro and the 12" MacBook, the firmware reports a
> framebuffer size of 2880x1800 but the screens are 2560x1600 and
> 2304x1440. Our console ends up drawing text off screen and the
> latest few lines can't be read.
>
> Once X loads, it probes the outputs again and uses the proper
> resolution.
>
> For the console, the outputs are already being probed but the BIOS
> resolution is only discarded if it's too small. I'd like to change
> it to discard it if it's too large as well, so it uses the actual
> resolution probed.
>
> On a machine like a server where inteldrm loads but has nothing
> connected, intel_fb is null, so this code doesn't run.
I'm hesitant to change this code. How does Linux behave on tese
machines? Does it use the invisible part of the framebuffer? Or have
they done away with actually using the kernel framebuffer completely
like some developers threatened a couple of years ago...
Do you have a (larger) monitor connected to your laptops when this happens?
Maybe the wsdisplay(4) interface code should be a bit more clever when
it initializes rasops and make sure we only use the part of the
framebuffer that is visible on all connected displays...
> Index: sys/dev/pci/drm/i915/intel_fbdev.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 intel_fbdev.c
> --- sys/dev/pci/drm/i915/intel_fbdev.c1 Jul 2017 16:14:10 -
> 1.3
> +++ sys/dev/pci/drm/i915/intel_fbdev.c23 Jul 2018 17:58:03 -
> @@ -202,10 +202,9 @@ static int intelfb_create(struct drm_fb_
> mutex_lock(>struct_mutex);
>
> if (intel_fb &&
> - (sizes->fb_width > intel_fb->base.width ||
> - sizes->fb_height > intel_fb->base.height)) {
> - DRM_DEBUG_KMS("BIOS fb too small (%dx%d), we require (%dx%d),"
> - " releasing it\n",
> + (sizes->fb_width != intel_fb->base.width ||
> + sizes->fb_height != intel_fb->base.height)) {
> + DRM_DEBUG_KMS("BIOS fb %dx%d != %dx%d, releasing it\n",
> intel_fb->base.width, intel_fb->base.height,
> sizes->fb_width, sizes->fb_height);
> drm_framebuffer_unreference(_fb->base);
>
>
Re: inteldrm: always use probed screen size for fb
On Wed, Jul 25, 2018 at 08:51:53AM +0100, Stuart Henderson wrote: > On 2018/07/24 13:25, Bryan Vyhmeister wrote: > > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > > not setting the clock with -s for some reason so rdate did the trick.) > > If the clock is already more than a little bit wrong and you have > "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it. Thanks for that info. This is with the default ntpd.conf which does indeed have constraints. I have not powered this system on for quite a while. I appreciate the explanation. Bryan
Re: inteldrm: always use probed screen size for fb
On 2018/07/25 06:10, Bryan Vyhmeister wrote: > On Wed, Jul 25, 2018 at 08:51:53AM +0100, Stuart Henderson wrote: > > On 2018/07/24 13:25, Bryan Vyhmeister wrote: > > > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > > > not setting the clock with -s for some reason so rdate did the trick.) > > > > If the clock is already more than a little bit wrong and you have > > "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it. > > Thanks for that info. This is with the default ntpd.conf which does > indeed have constraints. I have not powered this system on for quite a > while. I appreciate the explanation. > > Bryan The problem is that if the clock is wrong, the server's certificate and/or OCSP stapling can't be validated (it either appears to have expired, or not be valid yet), so ntpd is unable to connect using https to check the time. Personally I am no fan of "constraints", I use local NTP servers and trust the relevant parts of the network more than the RTC and batteries on my machines, and don't really like sending potentially fingerprintable external packets showing that a machine has rebooted, so I usually disable it. Obviously opinions differ on this :-)
Re: inteldrm: always use probed screen size for fb
On 2018/07/24 13:25, Bryan Vyhmeister wrote: > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > not setting the clock with -s for some reason so rdate did the trick.) If the clock is already more than a little bit wrong and you have "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it.
Re: inteldrm: always use probed screen size for fb
On Mon, Jul 23, 2018 at 01:28:40PM -0500, joshua stein wrote: > On the 2015 MacBook Pro and the 12" MacBook, the firmware reports a > framebuffer size of 2880x1800 but the screens are 2560x1600 and > 2304x1440. Our console ends up drawing text off screen and the > latest few lines can't be read. > > Once X loads, it probes the outputs again and uses the proper > resolution. > > For the console, the outputs are already being probed but the BIOS > resolution is only discarded if it's too small. I'd like to change > it to discard it if it's too large as well, so it uses the actual > resolution probed. > > On a machine like a server where inteldrm loads but has nothing > connected, intel_fb is null, so this code doesn't run. This makes a huge difference in usability for my 2015 12-inch MacBook (MacBook8,1)! I would love to see this committed. Thank you! Bryan (Obviously clock was wrong and I did not realize it. Looks like ntpd is not setting the clock with -s for some reason so rdate did the trick.) OpenBSD 6.3-current (GENERIC.MP) #0: Sat Dec 31 17:15:58 PST 2016 u...@host.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8469352448 (8077MB) avail mem = 8203497472 (7823MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afad000 (40 entries) bios0: vendor Apple Inc. version "MB81.88Z.0164.B32.1706181928" date 06/18/2017 bios0: Apple Inc. MacBook8,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP03(S4) ARPT(S4) RP04(S4) RP05(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 800.17 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 800.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu1: failed to identify cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 800.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu2: failed to identify cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz, 800.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 cpu3: failed to identify ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-52 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus 4 (RP01) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 3 (RP05) acpicpu0 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@530
inteldrm: always use probed screen size for fb
On the 2015 MacBook Pro and the 12" MacBook, the firmware reports a
framebuffer size of 2880x1800 but the screens are 2560x1600 and
2304x1440. Our console ends up drawing text off screen and the
latest few lines can't be read.
Once X loads, it probes the outputs again and uses the proper
resolution.
For the console, the outputs are already being probed but the BIOS
resolution is only discarded if it's too small. I'd like to change
it to discard it if it's too large as well, so it uses the actual
resolution probed.
On a machine like a server where inteldrm loads but has nothing
connected, intel_fb is null, so this code doesn't run.
Index: sys/dev/pci/drm/i915/intel_fbdev.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 intel_fbdev.c
--- sys/dev/pci/drm/i915/intel_fbdev.c 1 Jul 2017 16:14:10 - 1.3
+++ sys/dev/pci/drm/i915/intel_fbdev.c 23 Jul 2018 17:58:03 -
@@ -202,10 +202,9 @@ static int intelfb_create(struct drm_fb_
mutex_lock(>struct_mutex);
if (intel_fb &&
- (sizes->fb_width > intel_fb->base.width ||
-sizes->fb_height > intel_fb->base.height)) {
- DRM_DEBUG_KMS("BIOS fb too small (%dx%d), we require (%dx%d),"
- " releasing it\n",
+ (sizes->fb_width != intel_fb->base.width ||
+sizes->fb_height != intel_fb->base.height)) {
+ DRM_DEBUG_KMS("BIOS fb %dx%d != %dx%d, releasing it\n",
intel_fb->base.width, intel_fb->base.height,
sizes->fb_width, sizes->fb_height);
drm_framebuffer_unreference(_fb->base);
