OP
- Thread Starter
- #51
Tried that, no go. ?
Tried that, no go. ?
The first time I try GhostBSD I had a mouse problem doesn't click till I plug it out and plug it in when I decide to try it again I didn't download the same ISO I download the latest one and I didn't have that issue, I know it doesn't make sense but this is what happens to me ¯\_(ツ)_/¯
Just a few weeks ago, I tried playing with a 14-CURRENT boot iso on my Zephyrus. And, I discovered that the secret to making the keyboard register is frankly holding down the shift key as I type. In that case, the letters came out all lower-case. Pressing the Caps Lock key once (and still holding the shift key down afterwards) did make the letters come out in upper-case.
~,@,#,%,^,&,*,(,),_,+,{,},|,:,",<,>,?...completely different , enjoy , synaptics works perfectly
I have, and it works perfect, but kind of defeats the purpose.
Just thinking out loud ...
I tried 13.1, 13.2, -RELEASE, -STABLE, everything. Same problem, no matter the version of FreeBSD...
I was suggesting this as a way to aid in debugging the issue, not a permanent fix. With a working keyboard on a machine, you can do things like booting it in verbose mode, turning on various debug knobs, etc. Sometimes, this (logs) helps to debug and pinpoint an issue, if you open a PR and describe the problem to the best of your ability.
I never said that you didn't try it; my advice was for others in this thread with the same problem - in case they didn't read the whole thread.
set hint.atkbd.0.flags="0x05"
set hw.usb.no_boot_wait=1
bootkldload atkbdset kern.vty=vt
bootset hint.acpi.0.disabled=1
bootset boot_verbose=YES
bootHmm. The built-in keyboard issue seems tied to the AT keyboard controller (atkbdc) or Advanced Configuration and Power Interface (ACPI). Based on the dmesg logs, atkbdc0 and atkbd0 are recognized, but errors such as ACPI-related failures and a note about "non-PNP ISA device" looks like a possible ACPI misconfiguration or conflicts, possibly with modern hardware like your AMD Ryzen 9 system.
#!/bin/sh
{
echo 'hw.acpi.disabled=1'
echo 'hw.acpi.handle_reboot=1'
echo 'hint.atkbd.0.disabled="1"'
echo 'hint.atkbdc.0.disabled="1"'
} >> /boot/loader.confWow, 13.4-RELEASE works??? Seems like my chance to try that! There's gotta be some kind of difference between what's in that release and what I've been trying so far...
yellow carp`, per techpowerup.com), and dGPU is RX 6700S (`dimgrey cavefish`, per techpowerup.com). Important distinction to keep in mind! dGPU is the one connected to HDMI.vgapci0@pci0:3:0:0`. The dGPU is on `vgapci1@pci0:7:0:0`.pci:3:0:0`, not `pci0:3:0:0` (for iGPU)...There are two officially documented forms for use in the X config file:
vgapci1@pciW:X:Y:Z:, must be converted toBusID "PCI:X@W:Y:Z" (long form)BusID "PCI:X:Y:Z" (short form)@W is fully supported; I have not seen it documented in any official reference. Unfortunately in this instance that means also that the Handbook uses an undocumented form.vgapci1@pci0:0:2:1:, twice. While technically not incorrect, IF the there used variety of the long form actually works 100% of the time, the use of first two zeros, do not reveal that they need to be 'switched' when converting the pciconf -lv format to the X config file format (long form). See also my earlier message, including the relevant man pages.vgapci0@pci0:3:0:0BusID "PCI:3@0:0:0" (long form)BusID "PCI:3:0:0" (short form), which you used.
This is nice to know and have out in the open.
screen AND correct monitor (which are two separate things in Xorg's .conf file). When I ran Xorg -configure as per the Handbook, I discovered that it can see 6 or 7 screens, and 5 monitors... and did not want to go through 30+ different combinations, hoping to hit on the correct one that produces visibly running TWM. The strangest part is that besides the lack of visible output, the Xorg process actually launched without any (EE)-tagged lines written to the log file.