On 02/12/14 03:01, Jonathan Gray wrote: > On Wed, Feb 12, 2014 at 02:37:30AM -0500, RD Thrush wrote: >> 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? > > 1024x768 is the mode chosen if the monitor does not send > a mode when probed. > > If you want to make all of this a lot easier to debug > remove the radeon card.
This i7 only has onboard graphics. The other i7 has both graphics hardware. I only brought it up to corroborate the resolution and segfault problems seen in the initial report. >> >> >>> 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. > > Xorg -configure is known to be broken for quite a while > http://lists.freedesktop.org/pipermail/xorg/2013-June/055813.html > avoid it. Amending the faq[1] might help avoid this unproductive path... [1]<http://www.openbsd.org/faq/faq11.html#amd64i386example>