# Integrated Graphics (Unknown) on ASUS Prime B360M-A (Can't get Xorg running)



## StreetDancer (Sep 4, 2020)

Hey everyone!

Installed FreeBSD 12.1-RELEASE updated and I have tried so many different combinations of configurations and packages to try and get X launched.

Currently I have the following added to my /etc/rc.conf:


```
dbus_enable="YES"
hald_enable="YES"
kld_list="/boot/modules/i915kms.ko"
```

I also have "driver-intel.conf" in /usr/local/etc/X11/xorg.conf.d/ with the following contents:


```
Section "Device"
               Identifier "Card0"
               Driver     "intel"
               # BusID  "PCI:1:0:0"
EndSection
```

^ --- Have also tried with "PCI:0:2:0" which was identified in a Xorg.conf.new from a /root/ "Xorg -configure" command at one time. (I have formatted once so far. I accidently broke the /etc/rc.conf with the intel i915kms.ko without quotes on the end and it broke my start-up and I couldn't rescue with GELI for some reason.

Anyways...

In my /home/username/ i have ".xinitrc" which contains:


```
ck-launch-session dbus-launch --exit-with-session startlxde
exec startlxde
```

Normally this works like a charm. However... this is what happens when I kick off # startx from username:

* I cannot paste the full error because I do not know how* - Writing this post on a laptop.

```
Log file: "/var/log/Xorg.0.log"
Using config directory: "/usr/local/etc/X11/xorg.conf.d"
Using system config directory "/usr/local/share/X11/xorg.conf.d"
(EE)
Fatal server errror:
(EE) no screens found (EE)
(EE)
(EE) Server terminated with error (1) Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
```

Inside /var/log/Xorg.0.log I get :
* I am only putting lines that stand out to me here since I can't type it all up.

```
LoadModule: "glx"
LoadModule: "intel"
Intel: Driver for Intel(R) Integrated Graphics Chipsets: i819 - B43 (Very long list of supported models / drivers).
460.358 (II) intel: Driver for Intel(R) HD Graphics
460.358 (II) intel: Driver for Intel(R) Iris(TM) Graphics
460.358 (--) Using syscons driver with X support (version 2.0)
460.358 (--) Using VT number 9

460.361 (EE) No devices detected
460.361 (EE)
Fatal server error:
460:361  (EE) no screens found (EE)
```


I have gnome, kde and lxde using sddm login manager installed. (This is my standard setup on my other systems which have worked well).

Could it have to do with a BIOS setting? I am unfamiliar with contemporary computer hardware.

Thank you in advance.

If anyone knows what is wrong! Please let me know! Thanks 

Best Regards,

Brandon


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> Integrated Graphics (*Unknown*) on ASUS Prime B360M-A



Please run `# pciconf -vl | grep -B3 display`.



StreetDancer said:


> * I cannot paste the full error because I do not know how*



Please use misc/pastebinit. Usage `<command> | pastebinit`, e.g.: `cat /var/log/Xorg.0.log | pastebinit` will return an URL, post that URL.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Please run `# pciconf -vl | grep -B3 display`.
> 
> 
> 
> Please use misc/pastebinit. Usage `<command> | pastebinit`, e.g.: `cat /var/log/Xorg.0.log | pastebinit` will return an URL, post that URL.


T-Daemon,

Thanks for being bad*ss! 

First thing:

a) pciconf -vl | grep -B3 display returned the following:


```
vgapci0@pci0:0:2:0: class=0x030000 card=0x86941043 chip=0x3e988086 rev=0x02 hdr=0x00
        vendor         =  'Intel Corporation'
         device          =  'UHD Graphics 630 (Desktop 9 Series)'
         class             =  display
```

b) After installing 'pastebinit' ; I ran the query you set me up with and it output the following error regarding the DEV API being invalid:

root@local: /var/log # pastebinit Xorg.0.log | pastebinit and the output is :


```
Bad API request, invalid api_dev_key
```

Thank you very much, now I know my graphics card! 

Best Regards,

Brandon


----------



## StreetDancer (Sep 4, 2020)

After running your solution: I found the following thread: https://forums.freebsd.org/threads/...-no-screens-found-freebsd-12-0-release.71672/

I will look through this and see if It answers my hang up!

Thank you again!


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> root@local: /var/log # *pastebinit* *Xorg.0.log | pastebinit *and the output is :



Is it a typo or have you executed the command as is? The correct usage would be  `cat /var/log/Xorg.0.log | pastebinit`.


----------



## StreetDancer (Sep 4, 2020)

Perhaps it's not the solve I can understand in my situation.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Is it a typo or have you executed the command as is? The correct usage would be  `cat /var/log/Xorg.0.log | pastebinit`.


# cat /var/log/Xorg.0.log | pastebinit

output:


```
Bad API request, invalid api_dev_key
```


----------



## T-Daemon (Sep 4, 2020)

I can't test right now. Could be local with the executable or with pastebin.com. A quick web search doesn't return something conclusive.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> I can't test right now. Could be local with the executable or with pastebin.com. A quick web search doesn't return something conclusive.


I second that query result.


----------



## StreetDancer (Sep 4, 2020)

Camera Phone worked too


----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)

Thanks again for your help T-Daemon!


----------



## shkhln (Sep 4, 2020)

Most likely the gpu is not supported by drm-current-kmod-4.16.g20200320. I'm not sure whether you'll have to wait for FreeBSD 12.2 or 13.0.


----------



## T-Daemon (Sep 4, 2020)

Referring to 









						Intel UHD Graphics 630 support - No screens found - FreeBSD 12.0-RELEASE
					

Got a new server built on an Asrock Phantom Z390 ITX motherboard with an Intel core i9 9900 with integrated UHD Graphics 630, model BX80684I99900 (not the 9900K - this is the 65w version). The integrated graphics on this chipset are not supported by drm-kmod, or it's variant pkgs. I found this...




					forums.freebsd.org
				




you linked to, if the case is the missing pci id of the chip ( 0x3e98 ), then you need to patch. Currently the patch hasn't been merged into any of the drm-*kmod.


----------



## pebkac (Sep 4, 2020)

You should still be able to use the SCFB driver by simply installing 
	
	



```
xf86-video-scfb
```
 from packages/ports and letting xorg autoconfigure itself (i.e. move all the manual xorg graphics config files out of the way or delete them) if you do not want to install any prerelease FreeBSD versions. 

For me that works perfectly fine even with HiDPI on my brand new Dell from 2020 (fast enough for all office work, videos etc) and allows me to wait for FreeBSD 13 being released some time next year where I hope to switch to i915 drivers.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Referring to
> 
> 
> 
> ...


Last night before bed I attempted to install the patch and it said it was already installed. I believe I will have to wait before it works.


----------



## StreetDancer (Sep 4, 2020)

pebkac said:


> You should still be able to use the SCFB driver by simply installing
> 
> 
> 
> ...


pebkac,

I just checked that package and it has already been installed. I did what you said and have the following:

/etc/rc.conf:

I removed the i915kms.ko load

I removed all the .conf files within xorg's config.d directory and ran auto configure. I then copied from /root/xorg.conf.new to the xorg's config.d directory.

I went to the line where it said "intel" and changed it to "scfb"; restarted and startx worked liked a charm under 1024x768 graphics.

Is this the maximum resolution that you have right now? And thank you again for helping me get something on my screen until this gets resolved or I can acquire a compatible PCI Express Card!

As always... FreeBSD is Supreme! Thank you all for your time and expertise!

Thanks!

Best Regards,

~ Brandon


----------



## pebkac (Sep 4, 2020)

See https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html chapter 5.4.5 SCFB example, that is what I used.

You should not need anything else for graphics as far as I remember.

If it does not work, let me know, then I can have a second look at my configuration.


----------



## StreetDancer (Sep 4, 2020)

pebkac said:


> See https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html chapter 5.4.5 SCFB example, that is what I used.
> 
> You should not need anything else for graphics as far as I remember.
> 
> If it does not work, let me know, then I can have a second look at my configuration.


pebkac,

Take a look at my previous post again! I appreciate your SOLVE! 

1024x768 and running LXDE. Much obliged! 

I wonder how long it will take to get more than 1024x768 now.

Best Regards,

~ Brandon


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> Last night before bed I attempted to install the patch and it said it was already installed. I believe I will have to wait before it works.



Which port is it you tried to patch? I've looked in graphics/drm-fbsd12.0-kmod i915_pciids.h, but there is no hint of chip id 0x3E98.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Which port is it you tried to patch? I've looked in graphics/drm-fbsd12.0-kmod i915_pciids.h, but no hint of chip id 0x3E98.


T-Daemon,

I am trying to remember as I just wokeup within the last hour and my head is so groggy. I believe I was reading a thread that said the patch was old and since it was old the solution to check was to run a "make install clean" or "make reinstall clean" on port graphics/drm-fbsd12.0-kmod to check to see if the patch was applied.

I wish I could source this now. I did attempt a make reinstall from source and it was already installed correctly. (Apparently that assumed the patch doesn't/wouldn't make a difference).

I do not even understand the patch at this time.

Best Regards,

~ Brandon


----------



## shkhln (Sep 4, 2020)

The patch in question is included in 4.20 and later versions (as the brach labels under the commit message helpfully suggest). Now, drm-fbsd12.0-kmod is supposed to be updated to 5.4 (?) either somewhere around 12.2 release or after 12.1 EOL.

By the way, as an ESL speaker I absolutely hate "solve" being used as a noun. It's not cute and it requires me to read each sentence twice.


----------



## StreetDancer (Sep 4, 2020)

shkhln said:


> The patch in question is included in 4.20 and later versions (as the brach labels under the commit message helpfully suggest). Now, drm-fbsd12.0-kmod is supposed to be updated to 5.4 (?) either somewhere around 12.2 release or after 12.1 EOL.
> 
> By the way, as an ESL speaker I absolutely hate "solve" being used as a noun. It's not cute and it requires me to read each sentence twice.


shkhln,

The patch you say is included in 4.20; do you know if this is available in 13-snapshots 09/03/2020 image?

Regarding you being an ESL speaker; What do you prefer to see as opposed to "solve" ?

I have OCD/Autism with very little formal education at this time in life.

Thanks again for all your help!

Best Regards,

~ Brandon


----------



## Mjölnir (Sep 4, 2020)

"Solution" instead of "solve"?  StreetDancer, usually you don't need to invoke `Xorg --configure`, the _automagic_ works fine in most cases.  Concerning your resolution RTFM loader.conf(5): e.g. `efi_max_resolution="720p"` & vt(4): `kern.vt.fb.default_mode="<X>x<Y>"`/`kern.vt.fb.modes.<connector>="<X>x<Y>"` (in /boot/loader.conf). `grep vt.fb.modes /var/run/dmesg.boot` to see the names of screen _connectors_.


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> "Solution" instead of "solve"?  StreetDancer, usually you don't need to invoke `Xorg --configure`, the _automagic_ works fine in most cases.  Concerning your resolution RTFM loader.conf(5): e.g. `efi_max_resolution="720p"` & vt(4): `kern.vt.fb.default_mode="<X>x<Y>"`/`kern.vt.fb.modes.<connector>="<X>x<Y>"` (in /boot/loader.conf). `grep vt.fb.modes /var/run/dmesg.boot` to see the names of screen _connectors_.


mjollnir,

"Solution" instead of "solve"; I agree is more suitable. Many ways to discover/create solutions; and solve means the OP problem was resolved and the "Solution" is within the thread.

Regarding Xorg --configure ... I do not know how to utilize "automagic" or what it is. Everything following this from RTFM to screen connectors is 100% foreign to me. I am certain it's valuable and very important. 

Thank you!

Best Regards,

~ Brandon


----------



## shkhln (Sep 4, 2020)

StreetDancer said:


> The patch you say is included in 4.20; do you know if this is available in 13-snapshots 09/03/2020 image?



CURRENT already has drm-devel-kmod-5.4.58.g20200818, but we neither support nor recommend it here.


----------



## StreetDancer (Sep 4, 2020)

shkhln said:


> CURRENT already has drm-devel-kmod-5.4.58.g20200818, but we neither support nor recommend it here.


shkhln,

I understand the non-support or recommendation. It appears I am left with the following choices:

a) Enjoy a FreeBSD 12.1-Current LXDE experience in 1024x768 (Thank you all very much, btw).

b) Install CURRENT and cross my fingers it works!

c) Purchase a new graphics card in the meantime while I wait for RELEASE to patch intel915.

Thank you all again!

~ Best Regards,

Brandon


----------



## T-Daemon (Sep 4, 2020)

shkhln said:


> The patch in question is included in 4.20 and later versions (as the brach labels under the commit message helpfully suggest).



A search for 0x3E98 returns "no matching code found" I've checked some of the branches manually, but no hint to the device id. Have I  overlooked something?

If the case is only the device id shouldn't it be sufficient to add the missing id manually to i916_pciids.h instead of waiting until 4.20, or is there more behind?

User *ateslik *from Thread intel-uhd-graphics-630-support-no-screens-found-freebsd-12-0-release.71672 claims to have the issue resolved by adding the id.


----------



## shkhln (Sep 4, 2020)

T-Daemon said:


> A search for 0x3E98 returns "no matching code found"



GitHub's search is very imprecise and certainly not exhaustive.



T-Daemon said:


> I've checked some of the branches manually, but no hint to the device id. Have I something overlooked?



I can't really comment on this, other than that further development actually happens on https://github.com/freebsd/drm-kmod.


----------



## T-Daemon (Sep 4, 2020)

shkhln said:


> GitHub's search is very imprecise and certainly not exhaustive.



I see. I keep that in mind next time searching there.


----------



## Mjölnir (Sep 4, 2020)

StreetDancer said:


> Regarding Xorg --configure ... I do not know how to utilize "automagic" or what it is. Everything following this from RTFM to screen connectors is 100% foreign to me. I am certain it's valuable and very important.



Xorg(1) _automagic_: no configuration files at all, _Xorg_ figures all out itself
RTFM: _Read the fine manual, _although sometimes you can read it as _"Read the f*g manual"_...
grep(1) the connector name from /var/run/dmesg.boot as given above if you want to connect more than one monitor.
Else just set e.g. `kern.vt.fb.default_mode="1280x1024"` in loader.conf(5) to the maximum resolution of your screen & reboot.  But beware that applies to all monitors that you connect to that machine.  This should enable higher resolutions.  The scfb(4) video driver is sufficient for average desktop use-case unless you want 3D gaming or CAD/CAM or such.
When you have that, you can still try to patch your device ID into i915_pciids.h as kindly suggested by T-Daemon.  For that, you need to download the sources (usually, as _root_): EDIT No no no `make -C /usr/ports/x11-drivers/xf86-video-intel fetch` but instead: `make -C /usr/ports/graphics/drm-fbsd12.0-kmod fetch extract`.  Then, unpack the tar balls, patch your device ID into that file & `make install`.

Good luck!


----------



## T-Daemon (Sep 4, 2020)

shkhln said:


> ... further development actually happens on https://github.com/freebsd/drm-kmod.



There it is: "Add Missing PCI IDs":









						drm-kmod/i915_pciids.h at 25fed6326722dde2fbb776c3d000918393116d6e · freebsd/drm-kmod
					

drm driver for FreeBSD. Contribute to freebsd/drm-kmod development by creating an account on GitHub.




					github.com


----------



## T-Daemon (Sep 4, 2020)

*StreetDancer *why don't you give it a try, edit the file, add the id manually, install the driver, see what happens.


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> Xorg(1) _automagic_: no configuration files at all, _Xorg_ figures all out itself
> RTFM: _Read the fine manual, _although sometimes you can read it as _"Read the f*g manual"_...
> grep(1) the connector name from /var/run/dmesg.boot as given above if you want to connect more than one monitor.
> Else just set e.g. `kern.vt.fb.default_mode="1280x1024"` in loader.conf(5) to the maximum resolution of your screen & reboot.  But beware that applies to all monitors that you connect to that machine.  This should enable higher resolutions.  The scfb(4) video driver is sufficient for average desktop use-case unless you want 3D gaming or CAD/CAM or such.
> ...


mjollnir,

Thank you *very* much for this detailed response! It answered all of my questions and more. I also appreciate the dual layer of solutions. I appreciate the high hopes of "When you have that," and yes T-Daemon is someone I highly respect here and value his assistance as well!

Best Regards,

~ Brandon


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> There it is: "Add Missing PCI IDs":
> 
> 
> 
> ...


Nice find!


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> *StreetDancer *why don't you give it a try, edit the file, add the id manually, install the driver, see what happens.


T-Daemon,

More than happy to! Where am I to be patching this file? /usr/ports ? Then running a make reinstall or a make deinstall clean and then a make install clean ?


----------



## T-Daemon (Sep 4, 2020)

Run `portsnap fetch update`

In /usr/ports/graphics/drm-fbsd12.0-kmod

`# make fetch extract`

`# find work -name i915_pciids.h -exec vi {} +`

Find line:

/0x3E96

Copy & paste line

```
INTEL_VGA_DEVICE(0x3E96, info), /* SRV GT2 */ \
```
yy
p

Change the pasted line beneath the original from:

```
INTEL_VGA_DEVICE(0x3E96, info), /* SRV GT2 */ \

to

INTEL_VGA_DEVICE(0x3E98, info), /* SRV GT2 */ \
```

Place the cursor in pasted line over the 6, press x, press i, set 8, write & exit vi:
Esc
:wq

`# make reinstall clean`


----------



## Mjölnir (Sep 4, 2020)

Yes, you can patch that in the ports tree /usr/ports/x11-drivers/xf86-video-intel /usr/ports/graphics/drm-fbsd12.0-kmod, and then `make reinstall` (not _clean_ because that will delete your patch!), although the cleaner method would be to use poudriere(8) or synth(1) to build in a jail.  I'd say it's fine to build on the host (un-jail'ed) because it does not have any build dependencies. When you succeed (i.e. it runs without errors), you can upload your patch to GitHub or open a bug report (_x11-drivers/xf86-video-intel does not support xyz_) & file in your patch with that.


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> Yes, you can patch that in the ports tree /usr/ports/x11-drivers/xf86-video-intel, and then `make reinstall` (not _clean_ because that will delete your patch!), although the cleaner method would be to use poudriere(8) or synth(1) to build in a jail.  I'd say it's fine to build on the host (un-jail'ed) because it does not have any build dependencies. When you succeed (i.e. it runs without errors), you can upload your patch to GitHub or open a bug report (_x11-drivers/xf86-video-intel does not support xyz_) & file in your patch with that.


mjollnir,

I will upload to GitHub if it works! Not without proper credits to all of you, though.

I will return with results.


----------



## Mjölnir (Sep 4, 2020)

You can use the `edit` editor, that's easier for beginners than vi(1). Or, if you have a graphical desktop environment up & running, use the editor that comes with that.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Run `portsnap fetch update`
> 
> In /usr/ports/graphics/drm-fbsd12.0-kmod
> 
> ...


T-Daemon,

I have followed your instructions and have come to this juncture:

(vi confused my brain; I use nano) -- No disrespect on your instructions.

full path: /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/include/drm 

filename: "drm_pciids.h"

The following line is not found:

```
INTEL_VGA_DEVICE(0x3E96, info), /* SRV GT2 */ \
```

I cannot find any "0x3E96" entries at all in that file. 

Thanks again!


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> You can use the `edit` editor, that's easier for beginners than vi(1). Or, if you have a graphical desktop environment up & running, use the editor that comes with that.


Thank you! I am a nano fanatic! I have been using nano since it was called pico in Linux Distributions!


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> full path: /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/include/*drm*
> 
> filename: "*drm_pciids.h*"


The file is /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/include/drm/*i915*_pciids.h not *drm*_pciids.h.


----------



## StreetDancer (Sep 4, 2020)

I strike my last post as invalid! I was using the wrong file. The correct file is in the same directory and it's "i915_pciids.h" which contains the line that T-Daemon has outlined.

My apologies!


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> I strike my last post as invalid! I was using the wrong file. The correct file is in the same directory and it's "i915_pciids.h" which contains the line that T-Daemon has outlined.
> 
> My apologies!



No problem. To err is human.


----------



## StreetDancer (Sep 4, 2020)

Okay! I patched the file and all saved correctly on file "i915_pciids.h" 

full path: /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/include/drm

Line # 382 / 438

Full line:


```
INTEL_VGA_DEVICE(0x3E98, info), /* SRV GT2 */ \
```

Now when I run the following command from directory: "/usr/ports/graphics/drm-fbsd12.0-kmod/work/"

or "/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba" :

"make reinstall"

I receive the following error output:


```
make: don't know how to make reinstall. Stop
```

Thanks!


----------



## T-Daemon (Sep 4, 2020)

Return to /usr/ports/graphics/drm-fbsd12.0-kmod/, run the make command from there.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Return to /usr/ports/graphics/drm-fbsd12.0-kmod/, run the make command from there.


It re-installed; however I am not certain it included the work/ directory with patch.

I updated the /etc/rc.conf to reflect the i915 intel driver modules at start-up and I changed my xorg.conf from "vesa" to "intel".

I then ran "make reinstall" in "/usr/ports/graphics/drm-fbsd12.0-kmod" as T-Daemon suggested and the installation went fine. 

Following are pictures:


----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)

I do not know why every time I uploaded a picture it posted twice. My apologies. I couldn't remedy. (Some are multiple pages).


----------



## Mjölnir (Sep 4, 2020)

Did you apply your patch after `make extract` & before you did `make reinstall`?


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> Did you apply your patch after `make extract` & before you did `make reinstall`?


mjollnir,

Do you mean doing a "cp" with "i915_pciids.h" from

full path: /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-99da0ba/include/drm

to :

/usr/ports/graphics/drm-fbsd12.0-kmod/include/drm/ ?

If so; the answer is no. And this would explain why it didn't work if this patch does indeed work.

Would that be the right course of action?


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> I updated the /etc/rc.conf to reflect the i915 intel driver modules at start-up ..



I assume you have set in /etc/rc.conf `kld_list="/boot/modules/i915kms.ko` ( asking just to make sure )?



StreetDancer said:


> I changed my xorg.conf from "vesa" to "intel".



Have you installed x11-drivers/xf86-video-intel?


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> mjollnir,
> 
> Do you mean doing a "cp" with "i915_pciids.h" from
> 
> ...



Don't copy or move the file anywhere. It must remain where it is.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> I assume you have set in /etc/rc.conf `kld_list="/boot/modules/i915kms.ko` ( asking just to make sure )?
> 
> Yes sir!
> 
> Have you installed the x11-drivers/xf86-video-intel?


I most certainly have!



T-Daemon said:


> Don't copy or move the file anywhere. It must remain where it is.


T-Daemon,

Okay The file is still in the same place. I am at a loss and now confused!


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> Did you apply your patch after `make extract` & before you did `make reinstall`?


mjollnir,

I am not certain what you mean by apply my patch. If you mean editing the existing .h file and changing the 6 to an 8 and saving it. Then issuing the command "make reinstall" ; then I would say after "make extract" which pulled down the package into "work" directory; then edited the .h file; saved the file; "make reinstall" (which worked) , reverted the rc.conf to intel and xorg.conf to intel and restarted the system and logged in as I normally would.

Thanks!


----------



## chrbr (Sep 4, 2020)

Dear StreetDancer,
regarding the patching or modification of i915_pciids.h you can generate a patch which survives an svn update.

First

```
cd /usr/ports/x11-drivers/xf86-video-intel
make clean
make fetch
make extract
make patch
```
Make a backup of the ./files/ and store it at a safe place, just to be sure. Go to the directory where i915_pciids.h is located and make a copy of the original file as i915_pciids.h.orig. Then change i915_pciids.h as desired. Afterwards generate the patch from the ports root directory as below.

```
cd /usr/ports/x11-drivers/xf86-video-intel
make makepatch
```
patch-src_i915_pciids.h has appeared in /usr/ports/x11-drivers/xf86-video-intel/files. Check if the changes are as desired. Then run `make clean` and restore the original files of that directory. The next time the port is build the include file will be patched, too.

This should be the resulting file - if I have changed the correct position:

```
--- src/i915_pciids.h.orig    2020-09-04 17:30:22 UTC
+++ src/i915_pciids.h
@@ -487,7 +487,7 @@
 #define INTEL_CFL_S_GT2_IDS(info) \
     INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
     INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
-    INTEL_VGA_DEVICE(0x3E96, info), /* SRV GT2 */ \
+    INTEL_VGA_DEVICE(0x3E98, info), /* SRV GT2 */ \
     INTEL_VGA_DEVICE(0x3E98, info), /* SRV GT2 */ \
     INTEL_VGA_DEVICE(0x3E9A, info)  /* SRV GT2 */
```


----------



## StreetDancer (Sep 4, 2020)

chrbr said:


> Dear StreetDancer,
> regarding the patching or modification of i915_pciids.h you can generate a patch which survives an svn update.
> 
> First
> ...


chrbr,

Thank you very much for such a detailed write-up to assist me with not having updates overwrite my patch. Awesome! 

I don't think this patch has been proven to work yet. Once it does! I will most certainly walk through these steps and reply back! Thank you again!!!

Best Regards,

~ Brandon


----------



## chrbr (Sep 4, 2020)

I hope it helps. The procedure and things around can be found in the Porters Handbook https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html. The link refers to the patching. It just uses `diff -u` and manual copy instead of `make makepatch`. First everything sounds like black magic, but it is well documented and helps to understand the ports system.


----------



## T-Daemon (Sep 4, 2020)

Things are getting mixed up here, lets slow down. 


chrbr said:


> regarding the patching or modification of i915_pciids.h you can generate a patch which survives an svn update.





chrbr said:


> cd /usr/ports/x11-drivers/xf86-video-intel
> make clean
> make fetch
> make extract
> make patch



*chrbr *I'm afraid you misunderstood the situation, x11-drivers/xf86-video-intel is not the port needing patching but graphics/drm-fbsd12.0-kmod.


----------



## chrbr (Sep 4, 2020)

T-Daemon said:


> *@chrbr *I'm afraid you misunderstood the situation, x11-drivers/xf86-video-intel is not the port needing patching but graphics/drm-fbsd12.0-kmod.


Ok, I misunderstood which port to modify. But my intention has been to show how to generate a patch. I can make the patch file for the other port, too.

[EDIT] Better not, `make extract` requires the kernel sources I do not have. I am not keen to download them, only if it is really wanted.


----------



## Mjölnir (Sep 4, 2020)

So did I...  (corrected my posts already)


----------



## T-Daemon (Sep 4, 2020)

Lets test the manually modified pciid file first, make the patch later. There is no sense in creating patches when the whole procedure doesn't end up.

According to



			Graphics - FreeBSD Wiki
		


x11-drivers/xf86-video-intel is optional and xorg.conf not needed. *StreetDancer *please remove / rename xorg.conf, and make sure you are in the member of the "video" group, check if the driver is loaded, run `kldstat`, if it's not restart or `kldload /boot/modules/i915kms.ko` the driver, then try `startx`.


----------



## chrbr (Sep 4, 2020)

T-Daemon said:


> First lets test the manually modified pciid file first, make the patch later. There is no sense in creating patches when the whole procedure doesn't end up.


This is clearly true. I have not so much experience in the X11 setup. Therefore I will better not interfer .


----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)




----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> Lets test the manually modified pciid file first, make the patch later. There is no sense in creating patches when the whole procedure doesn't end up.
> 
> According to
> 
> ...


My last posts are after I removed xorg.conf and my user is a member of "wheel" and I was told by the handbook, I believe that it's equal to video group. (Has always worked on everything else; including the vesa drivers).

We did however generate new errors on output that wasn't shown before.


----------



## Mjölnir (Sep 4, 2020)

`pw groupmod video -m streetdancer`  then logout & login the user to apply the change


----------



## T-Daemon (Sep 4, 2020)

StreetDancer said:


> my user is a member of "wheel" and I was told by the handbook I believe that it's equal to video group.



The installation message of drm-fbsd12.0-kmod insists that the user has to be a member of the video group.


```
Please ensure that all users requiring graphics are members of the
"video" group.
```


----------



## Mjölnir (Sep 4, 2020)

Oh yes, while we're at it, here's my Standard disclaimer  : install the docs: `pkg install {de,en}-freebsd-doc`, replace _de_ with your native tongue, and point your favorite browser to /usr/local/share/doc/freebsd.

You can add to the _ALIAS_ section of /usr/local/etc/pkg.conf `message: "query '[%C/%n] %M'",`, read through all `pkg message|less`, and apply the requested settings.


----------



## StreetDancer (Sep 4, 2020)

mjollnir said:


> `pw groupmod video -m streetdancer`  then logout & login the user to apply the change


# pw groupmod video -m brandon 
restarted and startx  resulted in the same error.


----------



## StreetDancer (Sep 4, 2020)

T-Daemon said:


> The installation message of drm-fbsd12.0-kmod insists that the user has to be a member of the video group.
> 
> 
> ```
> ...


T-Daemon,

I added the user to video group. No avail... same frame buffer message on startx.

No xorg.conf needed at all? No command to generate one? No basic skeleton frame one to utilize for testing?


----------



## Mjölnir (Sep 5, 2020)

Skeleton for xorg.conf.d(5): /usr/local/etc/X11/xorg.conf.d/{video.conf,HID.conf,monitors.conf,server-layout.conf}
Each of these files can be empty, you can choose the filenames freely (HID: human interface device, i.e. keyboard, mouse, joystick etc.).
You can run `Xorg -configure` to write an xorg.conf(5), and split it's contents up into your files under /usr/local/etc/X11/xorg.conf.d/.  But that's going to be the _automagic_ default anyway.  You can take that as a template for your changes, e.g. switch the video driver between _scfb_ & _intel_ in video.conf.  `Xorg -configure` is considered obsolete!
Does your console video resolution change to a higher resolution during bootup with `sysrc kld_list+=" /boot/modules/i915kms.ko"` + loader.conf(5): `kern.vt.fb.default_mode="<X>x<Y>"` when the i915kms.ko gets loaded?
Since the likelyhood that the scfb(4) driver works is higher than that the intel(4) driver + patched graphics/drm-kmod works, I'd suggest to try to get X11 up with scfb(4) and without intel(4) 1st.
Once that succeeds, proceed with the intel(4) driver for X11.


----------



## T-Daemon (Sep 5, 2020)

StreetDancer said:


> No xorg.conf needed at all? No command to generate one? No basic skeleton frame one to utilize for testing?



Not at the moment. First lets make sure that the i915 driver has attached correctly to the graphic card.

During system boot, when the boot messages are displayed, does the console flash ( this should happen when the i915 driver attaches correctly to the graphics device ) and does the screen resolution change, is it higher?

In the boot messages there should be `[drm] ...` lines, check if any of them indicate an error. Run `dmesg` after boot to inspect.

Does ( by xorg complained ) /dev/dri/card0 exist?


----------



## shkhln (Sep 5, 2020)

mjollnir said:


> You can run `Xorg -configure` to write an xorg.conf(5), and split it's contents up into your files under /usr/local/etc/X11/xorg.conf.d/.  But that's going to be the _automagic_ default anyway.  You can take that as a template for your changes, e.g. switch the video driver between _scfb_ & _intel_ in video.conf.



`Xorg -configure` has an entirely separate code path from autoconfiguration, this is essentially an abandoned part of the Xorg codebase. You are not supposed to use it.


----------



## T-Daemon (Sep 5, 2020)

StreetDancer said:


> # cat /var/log/Xorg.0.log | pastebinit
> 
> output:
> 
> ...



If the misc/pastebinit error continues, a workaround  can make it work again. Open /usr/local/bin/pastebinit with an editor, copy line 30 to line 31 and change the default pastebin. No need to laboriously upload pictures from a smartphone.

```
30 #defaultPB = "pastebin.com"
31 defaultPB = "paste.ubuntu.com"
```

Or better use http://termbin.com. Example: `cat Xorg.0.log | nc termbin.com 9999`.


----------



## haricot (Sep 20, 2020)

StreetDancer said:


> Hey everyone!
> 
> Installed FreeBSD 12.1-RELEASE updated and I have tried so many different combinations of configurations and packages to try and get X launched.
> 
> ...


I am unsure if this will help but in the absence of other more erudite ideas I will tell you that I have an Asus A68HM and I cannot get xorg to function unless i use the vesa driver of 12.1. xorg -configure will set 'modsetting' automatically as driver. My solution works for my Asus with every flavour of freebsd.


----------

