Re: GOP and using monitor
Hello RVP, On Fri, Oct 8, 2021 at 11:10 PM RVP wrote: > > On Fri, 8 Oct 2021, Riza Dindir wrote: > > > I taught that I will do the hack, but leave the configuration in tact as > > > > genfb* at pci? dev ? function ? > > > > Anyways I will do this again. The status of the genfb before the new kernel > > is this (at this stage the system uses the stock kernel, > > which is the GENERIC kernel). > > > > [ 1.017054] genfb0 at pci0 dev 1 function 0: vendor 1002 product 1309 > > (rev. 0x00) > > [ 1.017054] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, > > stride 5632 > > [ 1.017054] genfb0: shadow framebuffer enabled, size 4224 KB > > [ 1.017054] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > > emulation), using wskbd0 > > [ 1.017054] drm at genfb0 not configured > > [ 1.017054] genfb1 at pci1 dev 0 function 0: vendor 1002 product 6604 > > (rev. 0x00) > > > > At this stage both the devices are not shown as "not configured". > > > > genfb0 is configured. Only drm is not configured. drm is not configured, because i do not have the radeon driver. That's what I think. > > > I have done this in the renamed kernel configuration. > > > > #genfb* at pci? dev ? function ? > > genfb0 at pci1 dev 0 function 0 > > genfb1 at pci0 dev 1 function 0 > > > > You can remove the genfb1 line. If I remove that line, I think it will not configure the device on pci0 dev 1 func 0. Will try. > > > I am in /usr/src/sys/arch/amd64/conf and configure the kernel using > > > > # config GENERIC_RADEON_GENFB > > Build directory is ../compile/GENERIC_RADEON_GENFB > > Don't forget to run "make depend" > > > > Then I do this to compile the kernel. > > > > # cd ../compile/GENERIC_RADEON_GENFB/ > > # make depend > > # make > > > > The build.sh method (also in the Guide) is simpler. I tried the build.sh, but it gave me an error looking for /usr/obj or a directory under /usr directly. So I settled with the manual method. > > > Here is the output for the genfb devices from the dmesg. > > > > [ 1.016985] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 > > (rev. 0x00) > > [ 1.016985] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, > > stride 5632 > > [ 1.016985] genfb0: shadow framebuffer enabled, size 4224 KB > > [ 1.016985] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > > emulation), using wskbd0 > > [ 1.016985] drm at genfb0 not configured > > [ 1.016765] genfb1 at pci0 dev 1 function 0: vendor 1002 product 1309 > > (rev. 0x00) > > [ 1.016765] genfb1: framebuffer at 0xe000, size 1366x768, depth 32, > > stride 5632 > > [ 1.016765] genfb1: shadow framebuffer enabled, size 4224 KB > > [ 1.016765] wsdisplay0 at genfb1 kbdmux 1: console (default, vt100 > > emulation), using wskbd0 > > [ 1.016765] drm at genfb1 not configured > > [ 1.016765] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 > > (rev. 0x00) > > > > This looks more like what we want. Just remove the genfb1 from the > kernel config. OK. Will do. > > > It does the correct thing and puts the 6604 on genfb0 device. This also > > does assign the same framebuffer to both genfb0 and genfb1. > > Wouldn't this mean that both the monitor and the will use the same > > framebuffer memory, and so if everything works fine as we assume > > (the VGA output is enabled), the monitor should display the same output as > > the laptop monitor? > > > > On 9.2, the addresses printed are virtual addresses. If they were the > _same_ physical addresses, then that would be a major bug. > Oh, I thought that it was the physical address. Alright. > Since NetBSD uses only one graphics card, just remove genfb1. Will do. > > -RVP Riza
Re: man page inquiry
Chavdar Ivanov wrote:
>> > original package might be buggy (autoconf substitutions use @
>> > not #) and needs a fix.
>>
>> You are no doubt quite correct with that suggestion. I will
>> carry it out as simply as I can manage.
>
> I don't think it is pkgsrc's fault - the original wdm.man.in file
> contains the #configdir# string, before 'make patch'. The executable
> uses the /usr/pkg/etc/wdm directory, as uwe@ surmised. A sed command
> to replace #configdir# with ${PKG_SYSCONFDIR} should suffice.
>From a quick look wdm already tries to replace them in its own
makefile by calling config.status, but config.status looks for @var@,
not #var#, so just patch the man page to have @ instead of # and it
should work I guess.
-uwe
Re: GOP and using monitor
On Fri, 8 Oct 2021, Riza Dindir wrote: I taught that I will do the hack, but leave the configuration in tact as genfb* at pci? dev ? function ? Anyways I will do this again. The status of the genfb before the new kernel is this (at this stage the system uses the stock kernel, which is the GENERIC kernel). [ 1.017054] genfb0 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00) [ 1.017054] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.017054] genfb0: shadow framebuffer enabled, size 4224 KB [ 1.017054] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.017054] drm at genfb0 not configured [ 1.017054] genfb1 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) At this stage both the devices are not shown as "not configured". genfb0 is configured. Only drm is not configured. I have done this in the renamed kernel configuration. #genfb* at pci? dev ? function ? genfb0 at pci1 dev 0 function 0 genfb1 at pci0 dev 1 function 0 You can remove the genfb1 line. I am in /usr/src/sys/arch/amd64/conf and configure the kernel using # config GENERIC_RADEON_GENFB Build directory is ../compile/GENERIC_RADEON_GENFB Don't forget to run "make depend" Then I do this to compile the kernel. # cd ../compile/GENERIC_RADEON_GENFB/ # make depend # make The build.sh method (also in the Guide) is simpler. Here is the output for the genfb devices from the dmesg. [ 1.016985] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) [ 1.016985] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.016985] genfb0: shadow framebuffer enabled, size 4224 KB [ 1.016985] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.016985] drm at genfb0 not configured [ 1.016765] genfb1 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00) [ 1.016765] genfb1: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.016765] genfb1: shadow framebuffer enabled, size 4224 KB [ 1.016765] wsdisplay0 at genfb1 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.016765] drm at genfb1 not configured [ 1.016765] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) This looks more like what we want. Just remove the genfb1 from the kernel config. It does the correct thing and puts the 6604 on genfb0 device. This also does assign the same framebuffer to both genfb0 and genfb1. Wouldn't this mean that both the monitor and the will use the same framebuffer memory, and so if everything works fine as we assume (the VGA output is enabled), the monitor should display the same output as the laptop monitor? On 9.2, the addresses printed are virtual addresses. If they were the _same_ physical addresses, then that would be a major bug. Since NetBSD uses only one graphics card, just remove genfb1. -RVP
Re: man page inquiry
On Fri, 8 Oct 2021, Chavdar Ivanov wrote:
A sed command to replace #configdir# with ${PKG_SYSCONFDIR}
should suffice.
Yes. However, /wm/wdm seems to be without a maintainer at
present, so I think there are no further steps I can take beyond
the "head's-up" I put up on pkgsrc-users earlier today.
Thank you.
--
"The existence of God is not an experimental issue in the way it was."
John Wisdom - "Gods" (1944)
Re: man page inquiry
On Fri, 8 Oct 2021 at 17:13, Bob Bernstein wrote:
>
> On Fri, 8 Oct 2021, Valery Ushakov wrote:
>
> >> Do you care to take a stab at what that value might be were it
> >> to be correctly displayed?
>
> > I don't have the slightest idea. /usr/pkg/etc/wdm probably.
>
> Yes, as was kindly pointed out to me by Martin in this post from
> only a few days ago:
>
> http://mail-index.netbsd.org/netbsd-users/2021/10/06/msg027871.html
>
> I am capable of such extreme obtuseness that even I myself get
> confused by it!
>
> > You should really report this to pkgsrc folks. I guess the
> > original package might be buggy (autoconf substitutions use @
> > not #) and needs a fix.
>
> You are no doubt quite correct with that suggestion. I will
> carry it out as simply as I can manage.
>
> Thank you again,
I don't think it is pkgsrc's fault - the original wdm.man.in file
contains the #configdir# string, before 'make patch'. The executable
uses the /usr/pkg/etc/wdm directory, as uwe@ surmised. A sed command
to replace #configdir# with ${PKG_SYSCONFDIR} should suffice.
>
> --
> "No matter how big the problem is, you can always run away from it."
> Dom Irrera
--
Re: GOP and using monitor
Hell RVP On Fri, Oct 8, 2021, 00:24 RVP wrote: > On Thu, 7 Oct 2021, Riza Dindir wrote: > > > > > I have tried first to change the GENERIC configuration, it changes to > > the genfb0 to use the other output. But did not work. > > > > Hmm. Can you post a dmesg for this? > > > I have then tried the hack, and the dmesg output is as such: > > > > [ 1.016451] genfb1 at pci0 dev 1 function 0: vendor 1002 product > 1309 (rev. 0x00) > > [ 1.016451] genfb1: framebuffer at 0xe000, size 1366x768, depth > 32, stride 5632 > > [ 1.016451] genfb1: shadow framebuffer enabled, size 4224 KB > > [ 1.016451] wsdisplay0 at genfb1 kbdmux 1: console (default, vt100 > emulation), using wskbd0 > > [ 1.016451] drm at genfb1 not configured > > [ 1.016451] genfb0 at pci1 dev 0 function 0: vendor 1002 product > 6604 (rev. 0x00) > > [ 1.017188] genfb0 at pci1 dev 0 function 0: vendor 1002 product > 6604 (rev. 0x00) > > [ 1.017188] genfb0: framebuffer at 0xe000, size 1366x768, depth > 32, stride 5632 > > [ 1.017188] genfb0: shadow framebuffer enabled, size 4224 KB > > [ 1.017188] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 > emulation), using wskbd0 > > [ 1.017188] drm at genfb0 not configured > > > > This is not right. With the hack and the GENERIC config, you should see > something like: > > [...] pci0 dev 1 function 0 not configured > > Here's what I got from my kernel before it panicked (as there's now no > console if I disable my sole video card): > > [ 1.0333894] vendor 8086 product 0166 (VGA display, revision 0x09) at > pci0 dev 2 function 0 not configured > > Check that you've done the compilation and the patch right. > I taught that I will do the hack, but leave the configuration in tact as genfb* at pci? dev ? function ? Anyways I will do this again. The status of the genfb before the new kernel is this (at this stage the system uses the stock kernel, which is the GENERIC kernel). [ 1.017054] genfb0 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00) [ 1.017054] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.017054] genfb0: shadow framebuffer enabled, size 4224 KB [ 1.017054] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.017054] drm at genfb0 not configured [ 1.017054] genfb1 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) At this stage both the devices are not shown as "not configured". I have done this in the renamed kernel configuration. #genfb* at pci? dev ? function ? genfb0 at pci1 dev 0 function 0 genfb1 at pci0 dev 1 function 0 I am configuring the kernel as explained in this site ( https://www.netbsd.org/docs/guide/en/chap-kernel.html). I am using the manual method of compiling the kernel. And the sources are in /usr/src. The genfb_pci.c file does not have the hack. I am in /usr/src/sys/arch/amd64/conf and configure the kernel using # config GENERIC_RADEON_GENFB Build directory is ../compile/GENERIC_RADEON_GENFB Don't forget to run "make depend" Then I do this to compile the kernel. # cd ../compile/GENERIC_RADEON_GENFB/ # make depend # make Then I do this to save the old kernel and install the new kernel and reboot # mv /netbsd /netbsd.old # mv netbsd / Here is the output for the genfb devices from the dmesg. [ 1.016985] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) [ 1.016985] genfb0: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.016985] genfb0: shadow framebuffer enabled, size 4224 KB [ 1.016985] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.016985] drm at genfb0 not configured [ 1.016765] genfb1 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00) [ 1.016765] genfb1: framebuffer at 0xe000, size 1366x768, depth 32, stride 5632 [ 1.016765] genfb1: shadow framebuffer enabled, size 4224 KB [ 1.016765] wsdisplay0 at genfb1 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 1.016765] drm at genfb1 not configured [ 1.016765] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00) It does the correct thing and puts the 6604 on genfb0 device. This also does assign the same framebuffer to both genfb0 and genfb1. Wouldn't this mean that both the monitor and the will use the same framebuffer memory, and so if everything works fine as we assume (the VGA output is enabled), the monitor should display the same output as the laptop monitor? > -RVP > Riza
Re: man page inquiry
On Fri, 8 Oct 2021, Valery Ushakov wrote: Do you care to take a stab at what that value might be were it to be correctly displayed? I don't have the slightest idea. /usr/pkg/etc/wdm probably. Yes, as was kindly pointed out to me by Martin in this post from only a few days ago: http://mail-index.netbsd.org/netbsd-users/2021/10/06/msg027871.html I am capable of such extreme obtuseness that even I myself get confused by it! You should really report this to pkgsrc folks. I guess the original package might be buggy (autoconf substitutions use @ not #) and needs a fix. You are no doubt quite correct with that suggestion. I will carry it out as simply as I can manage. Thank you again, -- "No matter how big the problem is, you can always run away from it." Dom Irrera
Re: man page inquiry
Bob Bernstein wrote: >> Looks like a pkgsrc bug that failed to properly substitute the >> actual value before installing the man page. > > Do you care to take a stab at what that value might be were it > to be correctly displayed? I don't have the slightest idea. /usr/pkg/etc/wdm probably. You should really report this to pkgsrc folks. I guess the original package might be buggy (autoconf substitutions use @ not #) and needs a fix. -uwe
