ARM64 X11 display resolution

[karlis . mikelsons]

Hello,

I'm installing an OpenBSD VM on Apple Silicon laptop on top of VMware 
Fusion and Parralels but have hard time setting X11 resolution higher 
than default 1024x768 resolution. Has anyone had experience with this 
and can help me setting resolution higher? Ideally I would want it to be 
2560x1440 as I'm normally running OpenBSD VM on separate external 
display in full screen.


Prior to switching to Apple Silicon I was running OpenBSD VM on Apple 
Intel notebook with VMware Fusion without any issues.


$ dmesg | grep -e fb -e display -e OpenBSD
OpenBSD 7.3-current (GENERIC.MP) #2148: Tue Jun  6 00:14:53 MDT 2023
vendor "VMware", unknown product 0x0406 (class display subclass VGA, rev 
0x00) at pci0 dev 15 function 0 not configured

simplefb0 at mainbus0: 1024x768, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
wskbd0 at ukbd0: console keyboard, using wsdisplay0

$ cat /var/log/Xorg.0.log | grep wsfb
[   164.049] (II) LoadModule: "wsfb"
[   164.051] (II) Loading /usr/X11R6/lib/modules/drivers/wsfb_drv.so
[   164.052] (II) Module wsfb: vendor="X.Org Foundation"
[   164.053] (II) wsfb: driver for wsdisplay framebuffer: wsfb
[   164.053] (WW) Falling back to old probe method for wsfb
[   164.053] (II) wsfb(0): using default device
[   164.054] (**) wsfb(0): Depth 24, (--) framebuffer bpp 32
[   164.054] (==) wsfb(0): RGB weight 888
[   164.054] (==) wsfb(0): Default visual is TrueColor
[   164.054] (==) wsfb(0): Using gamma correction (1.0, 1.0, 1.0)
[   164.054] (II) wsfb(0): Vidmem: 3072k
[   164.054] (**) wsfb(0): Display dimensions: (596, 335) mm
[   164.054] (**) wsfb(0): DPI set to (43, 58)
[   164.054] (**) wsfb(0): Using "Shadow Framebuffer"
[   164.063] (==) wsfb(0): Backing store enabled

I've tried forcing X11 to use vmware display driver, but it didn't work, 
and it appears that this display driver is not available for arm64:

$ ls /usr/X11R6/lib/modules/drivers/
amdgpu_drv.la
amdgpu_drv.so
ati_drv.la
ati_drv.so
modesetting_drv.la
modesetting_drv.so
radeon_drv.la
radeon_drv.so
wsfb_drv.la
wsfb_drv.so
wsudl_drv.la
wsudl_drv.so


Thanks,
Karlis

net.inet.ip.ifq missing

[karlis . mikelsons]

Hello,

After upgrade to OpenBSD 6.6 I noticed that net.inet.ip.ifq sysctl
metrics are no longer there. We used to monitor these values to see that
our firewalls are performing properly. Is there any other way to find
values of these counters?

Quick search through release notes and mailing lists didn't help me find
the answer.

Thanks!

Karlis

Re: Symon on 5.6

[karlis . mikelsons]

Hello,

for me, it didn't work as well. I (think I) did everything needed, 
including
rrdtool-chroot enable, and I had the same effect as you - no graphs. 
Only

after copying /bin/sh the graphs started working. I didn't do much
investigation though.
Oh and: I'm running nginx, if that matters.

Can you please share your nginx.conf?  I couldn't get Syweb to work with
Nginx no matter what I've tried.

Thanks!


--
Karlis

Re: HEADS-UP: issues with chromium in -current

[karlis . mikelsons]

Hello!


This is an older (still gtk+2 based) version of chromium: it doesn't
have this bug.
The bug started manifesting itself, when they switched to the new
Aura toolkit (since version 37 iirc).


It happened _after_ the switch to Aura which was in 36.0.1985.125 which
is the version that will be in 5.6 release packages, that one was ok.

Looking at chat logs, I first mentioned it in September, and I recall
that the problem definitely existed with the version immediately before
the use GPU accelerated cross process image transport on openbsd
as well commit - as I was hoping that might fix it :-).

I'm not totally sure because of the lock and lack of snapshots, but
I think 36.0.1985.143 is probably okay.


I can approve this, as I'm using Chromium 36.0.1985.143 (287914) on:
  OpenBSD 5.6-current (GENERIC.MP) #2: Fri Sep  5 15:59:11 EEST 2014
with Fluxbox for almost two months now, and it's working rock solid
without any issues whatsoever.


--
Karlis