On 02/11/14 19:45, Jonathan Gray wrote: > On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote: >> On 10 February 2014 13:11, RD Thrush <openbsd-m...@thrush.com> wrote: >>> With a somewhat recent i7 desktop, using startx, X seems to run ok; >>> however, at 1024x768 rather than the expected 1920x1200 resolution. >>> ctl-alt-keypad+ or - have no effect on resolution. ctl-alt-backspace >>> correctly reverts to text mode. I then tried Xorg -configure to look for >>> hints to improve resolution; however, that resulted in a segfault almost >>> immediately. >>> >> >> I'm pretty sure >> >> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06 >> >> is not supported in the sense of working as opposed to being >> recognized. i.e. 1024x768 is likely as good as it gets until support >> is added. Even 4400 is problematic at the moment. >> >> But I'm willing to be corrected by people more in the know. :-) > > Haswell graphics should work since a few months now.
It does work; however, only @ vesa 1024x768 resolution. That same hardware yields 1920x1200 w/ win7. Is 1024x768 the upper limit for -current w/ vga and this graphics hardware? > X segfaulting at a low address normally means the framebuffer > could not be mmap'd due to the /dev/drm* permissions not > being set correctly. Here's what I have: a8v2:home/rd 2181>ls -l /dev/drm* crw------- 1 root wheel 87, 0 Jan 24 02:58 /dev/drm0 crw------- 1 root wheel 87, 1 Jan 24 02:58 /dev/drm1 crw------- 1 root wheel 87, 2 Jan 24 02:58 /dev/drm2 crw------- 1 root wheel 87, 3 Jan 24 02:58 /dev/drm3 I didn't expect those perms to matter w/ Xorg -configure -keepPriv. In any case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post but observed the same segfault. I had compiled xenocara w/ debug and included the gdb backtrace in the original message[1]. How may I provide more info about this segfault? [1]<http://marc.info/?l=openbsd-misc&m=139205596505418&w=2>
