Re: PineView not using the whole screen
> 2. How can I make the VGA the primary globaly, >so that users don't need to say that in their ~/.xsession ? As already mention by others, looking to our own xrandr -q output where the LVDM voice is missing it is evident that the problem is related to your hardware configuration. Following the suggestion of Crystal you can try managing it by the xorg.conf disabling also some of these options: Section "ServerFlags" # Option "AutoAddGPU" "on" # Option "AutoBindGPU" "on" EndSection Try to play also with: xrandr --listproviders xrandr --setprovideroutputsource == Nowarez Market
Re: PineView not using the whole screen
On Wed, Nov 29, 2023 at 07:23:48PM +0100, Jan Stary wrote: > (Same with other WM's, which makes me think > it's a X problem, not a wm problem.) It's an X 'feature'. You can have several physical displays, (monitor, television, projector, etc), that show the same desktop. Ignore for the moment the concept of one 'desktop' spanning several displays, that is different. Here we are talking about one 'desktop' which is shown in one way or another on several monitors or other devices. If those displays have the same resolution, (and refresh rate), then it's easy, you just send the same pixel data to all of them. If those displays have different resolutions, then something has to happen. You have various choices: Scale the display to fit, show only part of the display, etc, etc. Example: Maybe you have a laptop with 1920x1080 and you are doing a conference with a projector that only displays 1280x1024. In that case you might choose to display only the top-left part of the desktop on the projector, and use the right hand side for things that you only want to see on the laptop screen, (such as a clock, or other widget). But in that case, if you 'maximise' a window, you would probably only want it to size itself as 1280x1024 and fill the projector screen, not size as 1920x1080 to fill the laptop screen and have some missing on the smaller projector display. So it is not really an 'X problem' it's an intended feature. > 1. Why are there two "outputs" recognized >when the machine only has a (visible) VGA >connected by a VGA cable to the monitor? Because your hardware supports those outputs at a lower level. The board you have is a D525MW. There was another version of that board D525MWV which actually had the LVDM connector header on it. > 2. How can I make the VGA the primary globaly, >so that users don't need to say that in their ~/.xsession ? An xorg.conf similar to that which I sent you, (with the names of the outputs changed to what the machines actually have), does that on at least two multi-headed machines that I have here. However neither of those is using Pineview or the intel driver, they are much newer and using the modesetting driver. Off the top of my head I would try adding a monitor section for the lvds output and including: Option "Disable" "true" but that's just speculation as none of the machines I've tested required it.
Re: PineView not using the whole screen
On Nov 28 20:30:39, kolip...@exoticsilicon.com wrote: > On Sun, Nov 26, 2023 at 04:12:39PM +0100, Jan Stary wrote: > > Can I make the VGA output the default globaly, so that > > individual users don't need to xrandr in their .xsession? > > Does this /etc/xorg.conf fix it? Thanks for the hint, but no. See below. > Section "Device" > Identifier "My device" > Option "Monitor-VGA1" "My monitor" > EndSection > > Section "Monitor" > Identifier "My monitor" > Option "Primary" "true" > Option "PreferredMode" "1680x1050" > EndSection The Xorg log has this to say (full log below): [ 9246.525] (II) intel(0): switch to mode 1680x1050@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 9246.555] (II) intel(0): switch to mode 1280x800@58.1 on LVDS1 using pipe 1, position (0, 0), rotation normal, reflection none [ 9246.573] (II) intel(0): Setting screen physical size to 430 x 270 So it recognizes the modes for the two putputs, and even recognizes the right physical size. But I am still seeing the same problem: a "maximalized" window will only occupy the upper left 1280x800 rectangle of the full 1680x1050 screen. Upon loging in via xenodm, xrandr says: Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 338mm x 211mm 1280x800 58.14*+ 1280x720 59.8659.74 1024x768 60.00 1024x576 59.9059.82 960x540 59.6359.82 800x600 60.3256.25 864x486 59.9259.57 640x480 59.94 720x405 59.5158.99 640x360 59.8459.32 VGA1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.95*+ 1280x1024 75.0260.02 1280x960 60.00 1152x864 75.00 1024x768 75.0360.00 832x624 74.55 800x600 75.0060.3256.25 640x480 75.0059.94 720x400 70.08 VIRTUAL1 disconnected (normal left inverted right x axis y axis) So the 1680x1050 mode is set, but that is only a mode of the VGA, which is _not_ the primary, LVDS is. Upon making VGA the primary via xrandr, as described before, the problem disappears, i.e. the running cwm starts making full screen windows full screen. (Same with other WM's, which makes me think it's a X problem, not a wm problem.) Repeating myself: does anyone please know th following? 1. Why are there two "outputs" recognized when the machine only has a (visible) VGA connected by a VGA cable to the monitor? 2. How can I make the VGA the primary globaly, so that users don't need to say that in their ~/.xsession ? Jan [ 9246.081] (--) checkDevMem: using aperture driver /dev/xf86 [ 9246.133] (--) Using wscons driver on /dev/ttyC4 [ 9246.171] X.Org X Server 1.21.1.9 X Protocol Version 11, Revision 0 [ 9246.171] Current Operating System: OpenBSD bzm.stare.cz 7.4 GENERIC.MP#1468 amd64 [ 9246.171] [ 9246.171] Current version of pixman: 0.42.2 [ 9246.171]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 9246.171] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 9246.173] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov 29 19:08:08 2023 [ 9246.174] (==) Using config file: "/etc/xorg.conf" [ 9246.174] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 9246.175] (==) No Layout section. Using the first Screen section. [ 9246.175] (==) No screen section available. Using defaults. [ 9246.175] (**) |-->Screen "Default Screen Section" (0) [ 9246.175] (**) | |-->Monitor "" [ 9246.177] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 9246.177] (**) | |-->Device "My device" [ 9246.177] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 9246.177] (==) Automatically adding devices [ 9246.177] (==) Automatically enabling devices [ 9246.177] (==) Not automatically adding GPU devices [ 9246.177] (==) Automatically binding GPU devices [ 9246.177] (==) Max clients allowed: 256, resource mask: 0x1f [ 9246.178] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 9246.178] (==) ModulePath set to "/usr/X11R6/lib/modules" [ 9246.178] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [ 9246.178] (II) Loader magic: 0x4ff320a1530 [ 9246.178] (II)
Re: PineView not using the whole screen
> Can I make the VGA output the default globaly? I have some board from ASRock Industrial with VGA and LVDS outputs. There is a BIOS settings for my model where I can choose what to enable and what will be the primary. When I let both outputs enabled, the BIOS messages appears only on the primary output. I think OpenBSD has nothing to do with the default monitor succession, it just gets what BIOS gives.
Re: PineView not using the whole screen
On Oct 20 16:46:32, h...@stare.cz wrote: > This is current/amd64 on a PC (dmesg and X log below). > > It seems that both X and the console only use > a portion of the available screen, in the upper left corner. > Please see the lame jpegs (sorry): > > the console > http://stare.cz/.tmp/fs4.jpeg > > the xenodm login screen > http://stare.cz/.tmp/fs3.jpeg > > a maximalized xterm with a tmux session > http://stare.cz/.tmp/fs2.jpeg > > a maximalized firefox window > http://stare.cz/.tmp/fs1.jpeg > > (Maximalized means cwm's ctrl+alt+f, > but it's the same with other window managers.) > > What's strange is that X somehow "knows" the actual size, > as the xconsole box is in the actual lower right corner. > > The booting sequence (white on blue) uses the whole screen, until > > inteldrm0: 1280x800, 32bpp > > where the monitor "blinks", and starting with > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > > the booting kernel only uses that portion of the scren. > That makes me *suspect* it's a inteldrm problem. According to xrandr -q Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 338mm x 211mm 1280x800 58.14*+ 1280x720 59.8659.74 1024x768 60.00 1024x576 59.9059.82 960x540 59.6359.82 800x600 60.3256.25 864x486 59.9259.57 640x480 59.94 720x405 59.5158.99 640x360 59.8459.32 VGA1 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.95*+ 1280x1024 75.0260.02 1280x960 60.00 1152x864 75.00 1024x768 75.0360.00 832x624 74.55 800x600 75.0060.3256.25 640x480 75.0059.94 720x400 70.08 Only one monitor is attached to the PC, with a VGA cable. Apparently, the X subsystem somehow recognizes two outputs, the LVDS1 and the VGA1, and considers the smaller LVDS, with its preferred mode of 1280x800, the primary. The mm dimensions reported are correct in that the 338x211 is exactly the portion of the not-full screen a "maximalized" window will use, while the monitor itself is 434x270 mm. (xdpyinfo also says the monitor is 338x211.) Setting xrandr --output VGA1 --primary works around the problem. Why are there two outputs recognized for the monitor? Can I make the VGA output the default globaly, so that individual users don't need to xrandr in their .xsession? Jan $ xrandr --verbose Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 LVDS1 connected 1280x800+0+0 (0x45) normal (normal left inverted right x axis y axis) 338mm x 211mm Identifier: 0x41 Timestamp: 982221 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: BACKLIGHT: 15625 range: (0, 15625) Backlight: 15625 range: (0, 15625) scaling mode: Full aspect supported: Full, Center, Full aspect link-status: Good supported: Good, Bad non-desktop: 0 range: (0, 1) 1280x800 (0x45) 68.900MHz -HSync -VSync *current +preferred h: width 1280 start 1292 end 1340 total 1440 skew0 clock 47.85KHz v: height 800 start 804 end 807 total 823 clock 58.14Hz 1280x720 (0x14f) 74.500MHz -HSync +VSync h: width 1280 start 1344 end 1472 total 1664 skew0 clock 44.77KHz v: height 720 start 723 end 728 total 748 clock 59.86Hz 1280x720 (0x150) 63.750MHz +HSync -VSync h: width 1280 start 1328 end 1360 total 1440 skew0 clock 44.27KHz v: height 720 start 723 end 728 total 741 clock 59.74Hz 1024x768 (0x151) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 1024x576 (0x152) 46.500MHz -HSync +VSync h: width 1024 start 1064 end 1160 total 1296 skew0 clock 35.88KHz v: height 576 start 579 end 584 total 599 clock 59.90Hz 1024x576 (0x153) 42.000MHz +HSync -VSync h: width 1024 start 1072 end 1104 total 1184 skew0 clock 35.47KHz v: height 576 start 579 end 584 total 593 clock 59.82Hz 960x540 (0x154) 40.750MHz -HSync +VSync h: width 960 start 992 end 1088 total 1216 skew0 clock 33.51KHz v: height 540 start 543 end 548 total 562 clock 59.63Hz 960x540 (0x155) 37.250MHz +HSync -VSync h: width 960 start 1008 end 1040 total 1120
Re: PineView not using the whole screen
zeloff wrote: > > Do you consider dangerous chflags to immutable /etc/bsd.re-config > > for the purpose eg. of a system rescue? > No. Received, thanks a lot. -- Daniele Bonini
Re: PineView not using the whole screen
> Do you consider dangerous chflags to immutable /etc/bsd.re-config for the > purpose eg. of a system rescue?No.--(sent from my phone apologies for shitty > formatting)
Re: PineView not using the whole screen
Zé Loff wrote: > man config > man boot_config > man bsd.re-config Do you consider dangerous chflags to immutable /etc/bsd.re-config for the purpose eg. of a system rescue ? -- Daniele Bonini
Re: PineView not using the whole screen
It's realy getting tiresome. Take your incoherent rambling somewhere else. On Oct 26 12:15:47, my2...@has.im wrote: > Well, here for a secure OpenBSD I'm expecting a minimal usage of resources. > But I see..if inserting my physical keyboard I get two keyboard devices > attached to run a sleep > button properly on a *consumer multimedia product* well..I missed mayb the > point and > everything is questionable. > > Then, if you are asking tips on how to attack my working station by injection > of keystrocks on a > pseudo keyboard device I have no clue but is it important indeed? > > ( I also asked you in my previous posts to stress test better this ucc driver > and parents because my bad > experiences with usb keyboards passing by an Aten KVM "Secure" switch, is it > anything enlightning? ) > > A little surprised, sincerelly. > > -- Daniele Bonini > > Oct 26, 2023 11:33:25 Crystal Kolipe : > > > On Thu, Oct 26, 2023 at 10:07:41AM +0200, Daniele B. wrote: > >> Just to specify I'm hoping you are going to solve this software issue in > >> the next releases (a properly running device driver is maybe better that > >> properly running sleep button at my side) > > > > What software issue are you talking about? > > > > Do you actually have any keyboards that don't work correctly with OpenBSD? > > > > What is the problem with the ucc driver attaching as well? Does it break > > anything? > >
Re: PineView not using the whole screen
Crystal Kolipe : > On Thu, Oct 26, 2023 at 03:43:20PM +0200, Daniele B. wrote: >> Thanks a lot, appreciated, I solved with 12$ more in my wallet now. > > Then you've saved enough cash to buy three of these: > > https://pckeyboard.com/page/product/PANIC Thinking we are all missing the OpenBSD red phone in silicon, in case there is no misc -- Daniele Bonini
Re: PineView not using the whole screen
On Thu, Oct 26, 2023 at 03:43:20PM +0200, Daniele B. wrote: > Thanks a lot, appreciated, I solved with 12$ more in my wallet now. Then you've saved enough cash to buy three of these: https://pckeyboard.com/page/product/PANIC
Re: PineView not using the whole screen
Thanks a lot, appreciated, I solved with 12$ more in my wallet now. I'm sure with these chapgpt guys among us they will start to appear keyboards by one "Pyhton" key .. Do not misunderstand, this is why I also "disable ucc" .. Barely, I'm absolutely a fan of that rare object named business keyboard. Extinction is approaching but still far, hopefully. -- Daniele Bonini Zé Loff wrote: > > Crystal Kolipe : > > > > >> Then, if you are asking tips on how to attack my working station > > >> by injection of keystrocks on a pseudo keyboard device I have no > > >> clue but is it important indeed? > > > > > > If you are concerned about that possibility then you can disable > > > the ucc driver. > > > > How to do that, please? > > Is it something easy that doesn't impact my OpenBSD 7.3 stable > > buddy ? > > > > -- Daniele Bonini > > > > man config > man boot_config > man bsd.re-config
Re: PineView not using the whole screen
On Thu, Oct 26, 2023 at 01:18:13PM +0200, Daniele B. wrote: > Crystal Kolipe : > > >> Then, if you are asking tips on how to attack my working station by > >> injection of keystrocks on a > >> pseudo keyboard device I have no clue but is it important indeed? > > > > If you are concerned about that possibility then you can disable the ucc > > driver. > > How to do that, please? > Is it something easy that doesn't impact my OpenBSD 7.3 stable buddy ? > > -- Daniele Bonini > man config man boot_config man bsd.re-config --
Re: PineView not using the whole screen
Crystal Kolipe : >> Then, if you are asking tips on how to attack my working station by >> injection of keystrocks on a >> pseudo keyboard device I have no clue but is it important indeed? > > If you are concerned about that possibility then you can disable the ucc > driver. How to do that, please? Is it something easy that doesn't impact my OpenBSD 7.3 stable buddy ? -- Daniele Bonini
Re: PineView not using the whole screen
On Thu, Oct 26, 2023 at 12:15:47PM +0200, Daniele B. wrote: > Well, here for a secure OpenBSD I'm expecting a minimal usage of resources. > But I see..if inserting my physical keyboard I get two keyboard devices > attached to run a sleep > button properly on a *consumer multimedia product* well..I missed mayb the > point and > everything is questionable. On your keyboard there is just one extra button. On other multimedia keyboards there might be a lot of extra buttons which are implemented separately to the regular keyboard keys. > Then, if you are asking tips on how to attack my working station by injection > of keystrocks on a > pseudo keyboard device I have no clue but is it important indeed? If you are concerned about that possibility then you can disable the ucc driver. But if a malicious USB device was going to inject keystrokes then it could do that just as easily using the normal keyboard device driver, so are you going to disable that as well? It could also inject mouse movements and clicks as a mouse device and copy and paste characters in to your terminal, so maybe you want to disable the mouse driver too. And even if you go out and buy a PS/2 keyboard and mouse so that you can disable the USB drivers, a malicious USB device could still attach as a network card so make sure you take steps to avoid that causing any problems. > ( I also asked you in my previous posts to stress test better this ucc driver > and parents because my bad > experiences with usb keyboards passing by an Aten KVM "Secure" switch, is it > anything enlightning? ) Well you didn't provide any debugging info about the problem with the KVM switch, and nothing to suggest that it was even related to the ucc driver. Common sense suggests that the injected keystroke are more likely to be some kind of 'reset' sequence that the switch sends when switching between the attached devices, or otherwise it's just buggy. Or both.
Re: PineView not using the whole screen
Well, here for a secure OpenBSD I'm expecting a minimal usage of resources. But I see..if inserting my physical keyboard I get two keyboard devices attached to run a sleep button properly on a *consumer multimedia product* well..I missed mayb the point and everything is questionable. Then, if you are asking tips on how to attack my working station by injection of keystrocks on a pseudo keyboard device I have no clue but is it important indeed? ( I also asked you in my previous posts to stress test better this ucc driver and parents because my bad experiences with usb keyboards passing by an Aten KVM "Secure" switch, is it anything enlightning? ) A little surprised, sincerelly. -- Daniele Bonini Oct 26, 2023 11:33:25 Crystal Kolipe : > On Thu, Oct 26, 2023 at 10:07:41AM +0200, Daniele B. wrote: >> Just to specify I'm hoping you are going to solve this software issue in >> the next releases (a properly running device driver is maybe better that >> properly running sleep button at my side) > > What software issue are you talking about? > > Do you actually have any keyboards that don't work correctly with OpenBSD? > > What is the problem with the ucc driver attaching as well? Does it break > anything?
Re: PineView not using the whole screen
On Thu, Oct 26, 2023 at 10:07:41AM +0200, Daniele B. wrote: > Just to specify I'm hoping you are going to solve this software issue in > the next releases (a properly running device driver is maybe better that > properly running sleep button at my side) What software issue are you talking about? Do you actually have any keyboards that don't work correctly with OpenBSD? What is the problem with the ucc driver attaching as well? Does it break anything?
Re: PineView not using the whole screen
Just to specify I'm hoping you are going to solve this software issue in the next releases (a properly running device driver is maybe better that properly running sleep button at my side) or I see a group of *users* moving to procure for themselves the right, standard, one device new keyboard.. I'm just here with a bunch of keyboards in my shopping carts, indeed. "Daniele B." wrote: > Crystal Kolipe wrote: > > > https://marc.info/?l=openbsd-tech=162922414816784 > > > Thanks for this one, Crystal: I just solved changing keyboard. > Indeed I had two usb keyboards with me and I passed from a > > Dell KB113T > > to a > > Dell KB212B > > this latter is running correctly using only one keyboard device. > > The difference between the two keyboards is just the sleep button > of the first one.
Re: PineView not using the whole screen
Crystal Kolipe wrote: > https://marc.info/?l=openbsd-tech=162922414816784 Thanks for this one, Crystal: I just solved changing keyboard. Indeed I had two usb keyboards with me and I passed from a Dell KB113T to a Dell KB212B this latter is running correctly using only one keyboard device. The difference between the two keyboards is just the sleep button of the first one. Note1: both usb keyboards listed above are chinese models for who likes these mind games. Note2: I also tried passing by a usb hub or not with the same keyboards having the same results. N.B: In the past, when I was still using my ATEN KVM (with the related OpenBSD USB ghost keyboard driver for it) I have been attacked a coupled of times by *injection of keys*. Unfortunately I do not know now if we are talking about the same usb driver in subject of the marc.info post you passed us. If you are interested to test further about it.. I need just to do a new *unboxing* of the ATEN KVM and I can give you more feedback about this situation. Surely, from that moment I gave up with the ATEN KVM.. (the *SECURE* ones as the model suggest, but indeed it depends on the driver I can imagine..). I hope you can investigate and stress test more on these such usb keyboard drivers, just reading this mark.info post I have my hair slidly popping up -- Daniele Bonini
Re: PineView not using the whole screen
On Fri, Oct 20, 2023 at 05:00:47PM +0200, Daniele B. wrote: > > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > > wskbd1: connecting to wsdisplay0 > > wskbd2: connecting to wsdisplay0 > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > Just to add, that these are my settings too, from a life and these don't > depend from 7.4. > I also wonders the same when it is about the two keyboards. https://marc.info/?l=openbsd-tech=162922414816784
Re: PineView not using the whole screen
On Fri, Oct 20, 2023 at 04:46:32PM +0200, Jan Stary wrote: > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69cb (27 entries) > bios0: vendor Intel Corp. version "MWPNT10N.86A.0069.2010.0913.1432" date > 09/13/2010 > bios0: Intel Corporation D525MW These are very old boards, we had one which was decomissioned some time ago but previously ran OpenBSD from release 5.0 up to some time around 6.2. I remember always seeing the same issue with only the top left 1280 x 800 portion of a 1920 x 1080 display used when it was on the console but I never bothered to investigate it further because the machine was mostly used headless. In X11 the it worked fine, (if slowly), using the whole 1920 x 1080 resolution. So this is not exclusively a new problem with this motherboard. Also, ours exhibited a strange bug with the USB subsystem in that the mouse stopped working every time the machine was powered off and on, and had to be physically disconnected and re-connected to be recognised again. No other USB peripherals suffered the same problem, and the mouse worked fine on other test machines.
PineView not using the whole screen
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > wskbd1: connecting to wsdisplay0 > wskbd2: connecting to wsdisplay0 > wsdisplay0: screen 1-5 added (std, vt100 emulation) Just to add, that these are my settings too, from a life and these don't depend from 7.4. I also wonders the same when it is about the two keyboards. -- Daniele Bonini
PineView not using the whole screen
This is current/amd64 on a PC (dmesg and X log below). It seems that both X and the console only use a portion of the available screen, in the upper left corner. Please see the lame jpegs (sorry): the console http://stare.cz/.tmp/fs4.jpeg the xenodm login screen http://stare.cz/.tmp/fs3.jpeg a maximalized xterm with a tmux session http://stare.cz/.tmp/fs2.jpeg a maximalized firefox window http://stare.cz/.tmp/fs1.jpeg (Maximalized means cwm's ctrl+alt+f, but it's the same with other window managers.) What's strange is that X somehow "knows" the actual size, as the xconsole box is in the actual lower right corner. The booting sequence (white on blue) uses the whole screen, until inteldrm0: 1280x800, 32bpp where the monitor "blinks", and starting with wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 the booting kernel only uses that portion of the scren. That makes me *suspect* it's a inteldrm problem. (It is also puzzling that the booting sequence ends with inteldrm0: 1280x800, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wskbd2: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) Needless to say, I only have one keyboard attached. Are there some devices being perhaps emulated as wskbds?) The X log starts with [27.357] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details so I rebooted with machdep.allowaperture=1 but that doesn't seem to have changed anything. X log for that is also below, the diff being mostly + (--) checkDevMem: using aperture driver /dev/xf86 + (II) AIGLX: Suspending AIGLX clients for VT switch Disabling inteldrm in the kernel (dmesg also below) makes the booting kernel use the whole screen the whole time, but xenodm does not even start with vga as opposed to inteldrm (is that expected)? -inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 -drm0 at inteldrm0 -intagp0 at inteldrm0 -agp0 at intagp0: aperture at 0xe000, size 0x1000 -inteldrm0: apic 8 int 16, PINEVIEW, gen 3 +vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 +wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) +wsdisplay0: screen 1-5 added (80x25, vt100 emulation) -wskbd0 at pckbd0: console keyboard +wskbd0 at pckbd0: console keyboard, using wsdisplay0 -inteldrm0: 1280x800, 32bpp -wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 -wsdisplay0: screen 1-5 added (std, vt100 emulation) How can I further debug this? Jan dmesg: OpenBSD 7.4-current (GENERIC.MP) #1411: Tue Oct 17 21:56:20 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8554905600 (8158MB) avail mem = 8275869696 (7892MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69cb (27 entries) bios0: vendor Intel Corp. version "MWPNT10N.86A.0069.2010.0913.1432" date 09/13/2010 bios0: Intel Corporation D525MW acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT acpi0: wakeup devices SLPB(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AZAL(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.19 MHz, 06-1c-0a, patch 0107 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu0: 512KB 64b/line 8-way L2 cache mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.27 MHz, 06-1c-0a, patch 0107 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu1: 512KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.24 MHz, 06-1c-0a, patch 0107 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu2: 512KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.34 MHz, 06-1c-0a, patch 0107 cpu3:
