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>

Reply via email to