From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] installing 9front on Dell Optiplex 790
Date: Sun, 1 May 2016 06:05:10 +0200 [thread overview]
Message-ID: <31b8e79ee083187b58bac044158ee402@felloff.net> (raw)
In-Reply-To: <CALCVq+Hm=TYU+xUdKi-aXeQnEy8K2N5U13J_z3LLMkqN6F=Wng@mail.gmail.com>
that message looks like its from trying to read edid info from
displayport. if theres nothing connected to displayport, and you
only use the vga connector, then it doesnt matter.
its hard to tell from your description if its an issue with the
fdi or the transcoder/port.
you might check the monitors OSD and see if it got a stable
signal. maybe the fdi is just misprogrammed sending garbage
digital data to the transcoder explaining the snow.
could you try a displayport->vga adapter? or a displayport monitor?
that might help distinguishing between the two scenarios.
some systematic debugging is needed to get that driver working.
i wonder why vesa doesnt work at all... you said you get a black
screen, so does that mean the monitor doesnt even turn on? (no signal)
maybe we hit some issue with realemu when setting up graphics,
but we dont see the error message? please run the commands
with filedescriptors 1 and 2 redirected to a logfile. or you
could connect to the machine with drawterm/cpu and then run
aux/vga from that with #i #v #$ and #P bound before /dev.
aux/vga has some experimental support for display selection, by
appending #N to the mode where N is display number counting from 1,
so you could also try aux/vga -m vesa -l '800x600x32#2' ect...
if we could get vesa to setup the graphics, even if not with
native resolution of your monitor, we can make a trace of all
register reads and writes and get some initial to start from.
you probably *just* want your graphics to work and not become
a driver programmer... but its difficult to write drivers
without access to the hardware and no way to test stuff...
and without any debug output, i cannot help you at all.
if this is a new machine, it might have support for UEFI, which
might provide us with a framebuffer... as a last resort...
if nothing works, try a diffrent computer or try a different
discrete graphics card maybe...
--
cinap
next prev parent reply other threads:[~2016-05-01 4:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-30 21:49 James
2016-04-30 21:57 ` [9front] " Nicolas Owens
2016-04-30 22:15 ` James
2016-04-30 22:47 ` cinap_lenrek
2016-04-30 22:39 ` cinap_lenrek
2016-05-01 0:43 ` James
2016-05-01 4:05 ` cinap_lenrek [this message]
2016-05-01 4:41 ` Matthew Veety
2016-05-01 4:51 ` sl
2016-05-01 7:19 ` Matthew Veety
2016-05-01 20:02 ` sl
2016-05-05 7:47 ` kokamoto
2016-05-05 10:53 ` kokamoto
2016-05-05 23:33 ` kokamoto
2016-05-05 23:56 ` cinap_lenrek
2016-05-06 0:33 ` kokamoto
2016-05-06 1:06 ` kokamoto
2016-05-06 5:29 ` kokamoto
2016-05-06 5:33 ` cinap_lenrek
2016-05-06 5:34 ` kokamoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31b8e79ee083187b58bac044158ee402@felloff.net \
--to=cinap_lenrek@felloff.net \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).