Testing the new i915 driver (rev. 3820047)

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Testing the new i915 driver (rev. 3820047)

Jean-Sébastien Pédron
Hi!

Lately, I fixed several issues with the GEM, people already reported
this improved things for them.

I believe I fixed two problems with the output connectors too and I hope
that it will be fine now for people who reported eg. non-working HDMI.
However, I can't test this myself.

I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).

As a reminder, informations are available on the wiki:
https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8

Please continue to test! Thank you for your help :)

--
Jean-Sébastien Pédron


signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Shawn Webb-3
On Sat, Oct 17, 2015 at 03:26:08PM +0200, Jean-S??bastien P??dron wrote:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)
>
> --
> Jean-S??bastien P??dron
>
Yay! I'll test HDMI connectivity out tonight and will report back.

New status to report: All applications, even OpenArena and Blender, work
100% for me on HardenedBSD with your patch applied.

Thanks,

--
Shawn Webb
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Robert Z-2
In reply to this post by Jean-Sébastien Pédron
I just built my main pc with a i7-4771 HD 4600 and your 10-17-15 patches.
It's finally working when I do kldload but there are red streaks on the top
monitor.

Thank you , Thank you
Jean
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Masachika ISHIZUKA
In reply to this post by Jean-Sébastien Pédron
  Hello, Jean.

  It remains sometimes panics. For example, 'less dmesg' within
kterm.
--
Masachika ISHIZUKA

Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #6 3820047(drm-i915-update-38): Sat Oct 17 23:03:56 JST 2015
    [hidden email]:/usr/obj/home/ishizuka/drm-i915-update-38/freebsd-base-graphics/sys/GENERIC amd64
FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1920x1080
CPU: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (2394.51-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45  Stepping=1
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7fdafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended Features=0x27ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8164700160 (7786 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <DELL CL09>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
ioapic0 <Version 2.0> irqs 0-39 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0xffffffff80edb490, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
cryptosoft0: <software crypto> on motherboard
acpi0: <DELL CL09   > on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_ec0: <Embedded Controller: GPE 0xa> port 0x62,0x66 on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
agp0: <Haswell ULT GT2 mobile> on vgapci0
agp0: aperture size is 256M, detected 32764k stolen memory
vgapci0: Boot video device
hdac0: <Intel Haswell HDA Controller> mem 0xf7d14000-0xf7d17fff irq 16 at device 3.0 on pci0
xhci0: <Intel Panther Point USB 3.0 controller> mem 0xf7d00000-0xf7d0ffff irq 16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0xffffffff
usbus0 on xhci0
pci0: <simple comms> at device 22.0 (no driver attached)
hdac1: <Intel Lynx Point-LP HDA Controller> mem 0xf7d10000-0xf7d13fff irq 22 at device 27.0 on pci0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pci2: <ACPI PCI bus> on pcib2
iwm0: <Intel Dual Band Wireless AC 7260> mem 0xf7c00000-0xf7c01fff irq 18 at device 0.0 on pci2
ehci0: <Intel Lynx Point LP USB 2.0 controller USB> mem 0xf7d1b000-0xf7d1b3ff irq 23 at device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
ahci0: <Intel Lynx Point-LP AHCI SATA controller> port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7d1a000-0xf7d1a7ff irq 19 at device 31.2 on pci0
ahci0: AHCI v1.30 with 3 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
acpi_button0: <Power Button> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
battery0: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
ppc0: cannot reserve I/O port range
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est2: <Enhanced SpeedStep Frequency Control> on cpu2
est3: <Enhanced SpeedStep Frequency Control> on cpu3
Timecounters tick every 1.000 msec
IPsec: Initialized Security Association Processing.
hdacc0: <Intel Haswell HDA CODEC> at cad 0 on hdac0
hdaa0: <Intel Haswell Audio Function Group> at nid 1 on hdacc0
pcm0: <Intel Haswell (HDMI/DP 8ch)> at nid 3 on hdaa0
hdacc1: <Realtek (0x0668) HDA CODEC> at cad 0 on hdac1
hdaa1: <Realtek (0x0668) Audio Function Group> at nid 1 on hdacc1
pcm1: <Realtek (0x0668) (Analog 2.0+HP/2.0)> at nid 20,21 and 18 on hdaa1
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <0x8086> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
iwm0: revision: 0x140, firmware 25.228 (API ver. 9)
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <LITEONIT LMT-256M6M mSATA 256GB DM8110F> ATA8-ACS SATA 3.x device
ada0: Serial Number TW0XXM305508536E0419
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
Timecounter "TSC-low" frequency 1197254154 Hz quality 1000
WARNING: WITNESS option enabled, expect reduced performance.
Root mount waiting for: usbus1 usbus0
uhub0: 13 ports with 13 removable, self powered
uhub1: 2 ports with 2 removable, self powered
Root mount waiting for: usbus1 usbus0
ugen0.2: <vendor 0x05e3> at usbus0
uhub2: <vendor 0x05e3 product 0x0610, class 9/0, rev 2.10/41.15, addr 1> on usbus0
uhub2: MTT enabled
ugen1.2: <vendor 0x8087> at usbus1
uhub3: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.04, addr 2> on usbus1
uhub2: 4 ports with 1 removable, self powered
uhub3: 8 ports with 8 removable, self powered
ugen0.3: <Logitech> at usbus0
Root mount waiting for: usbus0
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT
ugen0.4: <Unknown> at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
ugen0.4: <Generic> at usbus0
Root mount waiting for: usbus0
ugen0.5: <Intel Corporation> at usbus0
Root mount waiting for: usbus0
ugen0.6: <vendor 0x05e3> at usbus0
uhub4: <> on usbus0
uhub4: 4 ports with 1 removable, self powered
Root mount waiting for: usbus0
Root mount waiting for: usbus0
ugen0.7: <Verbatim> at usbus0
umass0: <Verbatim USB 3.0 External SSD, class 0/0, rev 3.00/1.10, addr 7> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:1:0: Attached to scbus1
da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
da0: <Verbatim USB External SSD PMAP> Removable Direct Access SPC-4 SCSI device
da0: Serial Number 070744FA2D24E807
da0: 400.000MB/s transfers
da0: 120384MB (246546432 512 byte sectors: 255H 63S/T 15346C)
da0: quirks=0x2<NO_6_BYTE>
ugen0.8: <ASIX Elec. Corp.> at usbus0
Trying to mount root from ufs:/dev/da0p3 [rw]...
WARNING: / was not properly dismounted
WARNING: /: mount pending error: blocks 24 files 1
lock order reversal:
 1st 0xfffff80008df0418 ufs (ufs) @ /home/ishizuka/drm-i915-update-38/freebsd-base-graphics/sys/kern/vfs_subr.c:2231
 2nd 0xfffffe01ea83f0e0 bufwait (bufwait) @ /home/ishizuka/drm-i915-update-38/freebsd-base-graphics/sys/ufs/ffs/ffs_vnops.c:263
 3rd 0xfffff80008ef55f0 ufs (ufs) @ /home/ishizuka/drm-i915-update-38/freebsd-base-graphics/sys/kern/vfs_subr.c:2231
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0233cbfd40
witness_checkorder() at witness_checkorder+0xe79/frame 0xfffffe0233cbfdc0
__lockmgr_args() at __lockmgr_args+0xd3b/frame 0xfffffe0233cbfe70
ffs_lock() at ffs_lock+0xa6/frame 0xfffffe0233cbfec0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x100/frame 0xfffffe0233cbfef0
_vn_lock() at _vn_lock+0x9a/frame 0xfffffe0233cbff60
vget() at vget+0x63/frame 0xfffffe0233cbffb0
vfs_hash_get() at vfs_hash_get+0xcc/frame 0xfffffe0233cc0000
ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0233cc0090
softdep_sync_buf() at softdep_sync_buf+0xad1/frame 0xfffffe0233cc0170
ffs_syncvnode() at ffs_syncvnode+0x256/frame 0xfffffe0233cc01f0
ffs_truncate() at ffs_truncate+0x6cd/frame 0xfffffe0233cc03e0
ufs_direnter() at ufs_direnter+0x7bb/frame 0xfffffe0233cc04b0
ufs_makeinode() at ufs_makeinode+0x5f3/frame 0xfffffe0233cc0670
ufs_create() at ufs_create+0x2d/frame 0xfffffe0233cc0690
VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe0233cc06c0
vn_open_cred() at vn_open_cred+0x2f8/frame 0xfffffe0233cc0830
kern_openat() at kern_openat+0x25c/frame 0xfffffe0233cc09a0
amd64_syscall() at amd64_syscall+0x2de/frame 0xfffffe0233cc0ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0233cc0ab0
--- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b5caca, rsp = 0x7fffffffd5a8, rbp = 0x7fffffffd690 ---
ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/19.00, addr 2> on usbus0
ums0: 4 buttons and [XYZ] coordinates ID=0
uhid0: <Intel Corporation IntelR Sensor Solution, class 0/0, rev 2.00/0.01, addr 5> on usbus0
axge0: <NetworkInterface> on usbus0
random: unblocking device.
miibus0: <MII bus> on axge0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 3 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
ue0: <USB Ethernet> on axge0
ue0: Ethernet address: 00:90:fe:bf:53:71
ue0: link state changed to DOWN
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
ue0: link state changed to UP
KLD linux_adobe.ko: depends on kernel - not available or version mismatch
linker_load_file: Unsupported file type

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

core.txt.9.xz (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Eric McCorkle-2
In reply to this post by Jean-Sébastien Pédron
Is it possible to build the driver directly into the kernel yet?  I
typically build all my commonly-used devices in, so I'd like to make
sure that use case works.

On 10/17/15 09:26, Jean-Sébastien Pédron wrote:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Robert Z-2
In reply to this post by Jean-Sébastien Pédron
Hi Jean

New patches dont work on a i7-4702HQ with a HIDPI display. I have attached
my logs. This is a dell laptop.

i7-4771 is working with lkdload i915kms. But when I start Gnome3 it crashes.
Nvidia drivers with gnome3 work though. This could be a configuration issue.


Thank you
Rob

On Sat, Oct 17, 2015 at 6:26 AM, Jean-Sébastien Pédron <[hidden email]
> wrote:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>
> As a reminder, informations are available on the wiki:
>
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)
>
> --
> Jean-Sébastien Pédron
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
In reply to this post by Jean-Sébastien Pédron
Hi,

thank you very much for your work on this.

I tried the latest version as of today (commit
382004782ca4960f1e25a890e8df21507ba9eb4f).
Unfortunately, it does not seem to work as I only get a black screen on
the console.

I tried with both kern.vty="vt" and kern.vty="sc".
Attached, I send the corresponding dmesg output for vt (dmesg.out) and
sc (dmesg.out.sc).
My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
I hope the dmesg out is helpful.

Again, thank you very very much for working on this.



BR,

Ruediger




On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)
>

--
http://ruedigergad.com

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

dmesg.out (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
Sorry, the second attachment got somehow removed.
I'm giving it another try as "dmesg.sc.out".




On 17.10.2015 21:15, Ruediger Gad wrote:

> Hi,
>
> thank you very much for your work on this.
>
> I tried the latest version as of today (commit
> 382004782ca4960f1e25a890e8df21507ba9eb4f).
> Unfortunately, it does not seem to work as I only get a black screen on
> the console.
>
> I tried with both kern.vty="vt" and kern.vty="sc".
> Attached, I send the corresponding dmesg output for vt (dmesg.out) and
> sc (dmesg.out.sc).
> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
> I hope the dmesg out is helpful.
>
> Again, thank you very very much for working on this.
>
>
>
> BR,
>
> Ruediger
>
>
>
>
> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
>> Hi!
>>
>> Lately, I fixed several issues with the GEM, people already reported
>> this improved things for them.
>>
>> I believe I fixed two problems with the output connectors too and I hope
>> that it will be fine now for people who reported eg. non-working HDMI.
>> However, I can't test this myself.
>>
>> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>>
>> As a reminder, informations are available on the wiki:
>> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>>
>> Please continue to test! Thank you for your help :)
>>
>
>
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>

--
http://ruedigergad.com

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

dmesg.sc.out (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Arto Pekkanen
In reply to this post by Jean-Sébastien Pédron
Testing Scenario #1:
1. boot the new kernel
   - do not load i915kms at boot
   - do not connect any external monitors
2. start Xorg from tty as normal user
3. test tty switching
4. connect and test multiple monitors (via HDMI2 and HDMI3 outputs)
5. test FullHD video output, look for problems in video playback
    - ESPECIALLY look for VSync issues

I am using FreeBSD 10.2-RELEASE userland, applications installed from
the official FreeBSD quarterly repository. I have configured syslogd to
output all kernel messages to /var/log/messages

My laptop is a Thinkpad T430, dual-core i5 (4 threads), Ivy Bridge with
Intel HD4000 GPU.

# cat /boot/loader.conf
kern.vt.fb.default_mode="1600x900"
kern.vt.fb.modes.LVDS-1="1600x900"
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
sem_load=YES
drm.debug=3

Kernel booted just fine, no problems.

Then I loaded the kernel module (as root):
# kldload i915kms

Module loaded without problems. Then I attempted to start Xorg (non-root
user):
$ startx

Xorg started without problems, single output on laptop LVDS1.

TTY switching works without any problems.

After this I connected 2 monitors to HDMI outputs HDMI2 and HDMI3 (they
were unplugged at boot). Then I configured two monitors:
xrandr --output HDMI2 --right-of LVDS1 --auto
xrandr --output HDMI3 --right-of HDMI2 --auto

I got all three monitors working at optimal resolution without problems.
Very good thus far.

But then I ran into a weird problem: NO X11 application would use
hardware acceleration. This would lead to display tearing and horrible
performance. Each application would output the following stderr:
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

Investigating the issue I found out that kernel devfs OR devd (not sure
which?) would set the /dev/dri/* permissions incorrectly. The gid of
/dev/dri/* was 44, and this gid 44 was nonexistant in /etc/groups. Where
does this gid 44 come from? Is it a group specific to the 11-CURRENT
kernel?

I managed to work around this problem with the following command (as
root):
# chgrp wheel /dev/dri/*

After this hardware acceleration worked fine (programs were able to
access /dev/dri/*, as my non-root user is member of the wheel -group).
HOWEVER, this fix is quick and dirty. I am correct to assume that this
won't be an issue when the driver is MFC'd?

Anyways, thus far I have tried using www/chromium and watched Youtube
videos. Video playback works fine without tearing (because I use
SNA+TearFree), chrome CPU usage around 30-60% with 1080p full HD video.
Within acceptable limits.

SUMMARY:
- boot ok
- kldload i915kms ok
- startx ok
   - NOTE: using SNA acceleration with TearFree option
- tty switching works ok
- all outputs detected and configured
   - HDMI2 and HDMI3
- needed to manually do 'chgrp wheel /dev/dri/*' to get hardware
acceleration working properly
- after the perm fix, chrome can play 1080p videos without any issues,
no video tearing

Test Scenario #1 was completed in about 30 minutes.

IMPORTANT: I used the same Xorg configuration for all these tests. The
relevant Xorg configuration files are attached in this email, please
browse thru them if they help.

NOTE1. dmesg was logged into /var/log/messages. the drm.debug=3 and
witness produced huge amount of output into /var/log/messages. The
actual dmesg at boot was not logged in this file, and I was NOT able to
save it, since the messages from debug+witness overrun dmesg buffer. I
should have done dmesg > dmesg.txt as the very first thing after boot. I
am sorry for failing to do this. However, I managed to get at least the
/var/log/messages output after I started X. I dare not attach the 2M+
file here, so you can download it from:
http://koti.kapsi.fi/~isoa/kernel.i915/scenario1/messages.log.xz

NOTE2. Do note that I use the SNA acceleration with the TearFree -option
(in 10-intel.conf), because the default UXA acceleration did not offer
VSync. Thus for me being a perfectionist, the only option is to use
SNA+TearFree to get a perfect video performance.

NOTE3. The only real problem I had was that I was NOT able to get my
wifi working! With the 10.2-RELEASE kernel, iwn0 attached fine, and I
was able to join my local wifi. However, with the new kernel.i915, there
is no iwn0 interface (via ifconfig), as if the new kernel.i915 could not
detect my wireless chip at all. Kernel in 10.2-RELEASE detected the
following:
iwn0: <Intel Centrino Advanced-N 6205> mem 0xf1c00000-0xf1c01fff at
device 0.0 on pci3

NOTE4: Chrome CPU usage of 1080p Youtube videos under Debian 8 (SNA
acceleration + TearFree) fall within this same 30-60% margin. Except,
with the newer KMS drivers in Debian, VSync is YET again bugged. With
Debian 8 I had to use Compton (with very specific settings) -compositor
to force VSync on the composition overlay. I tested this by adding Xorg
configuration for intel driver and pkilling Xorg, which should have
restarted Xorg with new config (if pkilling Xorg did not start X with
new intel config, then I blame systemd and/or the display manager that
is preconfigured with Debian 8 LXDE desktop). So yeah, my testing kinda
proves even the Linux drivers can have regressions. I have to say that
we are really lucky that this driver in kernel.i915 imported from Linux
3.8 does not have regression in regards to VSync with SNA+TearFree. I
think we FreeBSD users gotta stay sharp and keep torture testing these
drivers with all possible scenarios. This is the only way to make sure
that things are hopefully noticed and fixed even in upsteam.

I will prepare another scenario. In Test Scenario #2 I shall attempt the
following:
1. boot kernel.i915 with i915kms_load="YES"
2. startx as normal user
3. repeat steps 3 to 5 from Test Scenario #1

Jean-Sébastien Pédron kirjoitti 17.10.2015 16:26:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I
> hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for
> me).
>
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)
--
Arto Pekkanen
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

00-fonts.conf (1K) Download Attachment
10-intel.conf (1K) Download Attachment
20-outputs.conf (554 bytes) Download Attachment
Xorg.0.log (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Arto Pekkanen
In reply to this post by Jean-Sébastien Pédron
New information regarding OpenGL application hangs and core dumps.

Procedure
- boot with kernel.i915
   - do not load i915kms at loader
- startx as normal user OR xdm via /etc/ttys, no difference

Tested applications thus far: chrome, openarena, compton.

When I use SNA acceleration, I can get OpenGL applications to work
without core dumping. Sometimes fullscreen applications cause black
areas to emerge over regions of other windows, which go away after
resizing windows or doing something that triggers a redraw (damage
event, probably).

However, when I use UXA acceleration instead of SNA acceleration (by
removing my intel specific configuration OR setting UXA directly in
conf), openarena and compton both crash with core dump. Also, they blank
the screen, and to get display back I have to vt switch back and forth.

In short, the default UXA acceleration is broken for me in kernel.i915.
I must use SNA acceleration, which works most of the time, except when
it glitches so that damaged regions do not get redrawn.

My config for SNA:
# cat <<EOF >/usr/local/etc/X11/xorg.conf.d/10-intel.conf
> Section "Device"
> Identifier "Intel IGP"
> Driver "intel"
> Option "AccelMethod" "SNA"
> Option "TearFree" "true"
> EndSection

I will produce a Test Scenario for this later, but for now I will just
report my findings.

Jean-Sébastien Pédron kirjoitti 17.10.2015 16:26:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I
> hope
> that it will be fine now for people who reported eg. non-working HDMI.
> However, I can't test this myself.
>
> I'm still chasing a problem with Mesa (Stellarium hangs on startup for
> me).
>
> As a reminder, informations are available on the wiki:
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>
> Please continue to test! Thank you for your help :)

--
Arto Pekkanen
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Michael Gmelin-3
In reply to this post by Jean-Sébastien Pédron


On Sat, 17 Oct 2015 15:26:08 +0200
Jean-Sébastien Pédron <[hidden email]> wrote:

> Hi!
>
> Lately, I fixed several issues with the GEM, people already reported
> this improved things for them.
>
> I believe I fixed two problems with the output connectors too and I
> hope that it will be fine now for people who reported eg. non-working
> HDMI. However, I can't test this myself.
>

Tested the latest version on the Acer c720, HDMI works now, not only
video, but also audio (which is great).

There were a couple of red lines in the left upper corner of the
screen (which disappeared eventually):
http://blog.grem.de/bits/i915_1.jpg

Also had the problem of wrong permissions/group on /dev/dri/* another
user reported earlier.

chrome reports that MESA-LOADER doesn't recognize the PCI ID.

Suspend/resume doesn't work (machine boots on resume). When setting
sysctl debug.acpi.suspend_bound=1, the screen stays off until the
graphics mode is changed (e.g. start X). It shows the following message
at the console:

error: [drm:pid687:i915_write8] *ERROR* Unknown unclaimed register
before writing to 3b4
error: [drm:pid687:i915_write32] *ERROR* Unclaimed write to 70030
info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off

Thanks for working on this!
- Michael

--
Michael Gmelin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Shawn Webb-3
In reply to this post by Shawn Webb-3
On Sat, Oct 17, 2015 at 10:07:55AM -0400, Shawn Webb wrote:

> On Sat, Oct 17, 2015 at 03:26:08PM +0200, Jean-S??bastien P??dron wrote:
> > Hi!
> >
> > Lately, I fixed several issues with the GEM, people already reported
> > this improved things for them.
> >
> > I believe I fixed two problems with the output connectors too and I hope
> > that it will be fine now for people who reported eg. non-working HDMI.
> > However, I can't test this myself.
> >
> > I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
> >
> > As a reminder, informations are available on the wiki:
> > https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
> >
> > Please continue to test! Thank you for your help :)
> >
> > --
> > Jean-S??bastien P??dron
> >
>
> Yay! I'll test HDMI connectivity out tonight and will report back.
>
> New status to report: All applications, even OpenArena and Blender, work
> 100% for me on HardenedBSD with your patch applied.
Update: dual-screen with laptop monitor and HDMI is working 100%! You
are amazing!

Just a piece of interesting info. I do see this occasionally in my dmesg
buffer:

[26] error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns
[26] error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040

Those errors don't seem to be critical errors since nothing is crashing on me.

Thanks,

--
Shawn Webb
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Gary Jennejohn-6
In reply to this post by Arto Pekkanen
On Sun, 18 Oct 2015 03:05:25 +0300
Arto Pekkanen <[hidden email]> wrote:

> I managed to work around this problem with the following command (as
> root):
> # chgrp wheel /dev/dri/*
>

You can more easily fix this by setting the owner, e.g. root:wheel,
in /etc/devfs.conf.  You probably need an entry for each device
which can appear under /dev/dri.  See devfs.conf(5).

> NOTE1. dmesg was logged into /var/log/messages. the drm.debug=3 and
> witness produced huge amount of output into /var/log/messages. The
> actual dmesg at boot was not logged in this file
>

Use /var/run/dmesg.boot for the boot-time output.

--
Gary Jennejohn
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
In reply to this post by Ruediger Gad
PS:
Please excuse the noise.
Just another update:
Thanks to the hint of Arto, I tried once more with external screens
attached to all outputs (VGA & HDMI).

After kldload i915kms, the internal display turns off and the external
screens turn on.
In the console, I can see some red stripes at the top similar to what
Rob mentioned.
Starting X works and I can see the output on the external screens but
the internal screen remains black.
I can also change the resolution etc. via xrandr but, so far, I did not
manage to turn the internal display on.

Attached, I send a the Xorg.log and another dmesg output that was taken
while running X.

Again, thanks a lot for the work.



BR,

Ruediger




On 17.10.2015 21:38, Ruediger Gad wrote:

> Sorry, the second attachment got somehow removed.
> I'm giving it another try as "dmesg.sc.out".
>
>
>
>
> On 17.10.2015 21:15, Ruediger Gad wrote:
>> Hi,
>>
>> thank you very much for your work on this.
>>
>> I tried the latest version as of today (commit
>> 382004782ca4960f1e25a890e8df21507ba9eb4f).
>> Unfortunately, it does not seem to work as I only get a black screen on
>> the console.
>>
>> I tried with both kern.vty="vt" and kern.vty="sc".
>> Attached, I send the corresponding dmesg output for vt (dmesg.out) and
>> sc (dmesg.out.sc).
>> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
>> I hope the dmesg out is helpful.
>>
>> Again, thank you very very much for working on this.
>>
>>
>>
>> BR,
>>
>> Ruediger
>>
>>
>>
>>
>> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
>>> Hi!
>>>
>>> Lately, I fixed several issues with the GEM, people already reported
>>> this improved things for them.
>>>
>>> I believe I fixed two problems with the output connectors too and I hope
>>> that it will be fine now for people who reported eg. non-working HDMI.
>>> However, I can't test this myself.
>>>
>>> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>>>
>>> As a reminder, informations are available on the wiki:
>>> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>>>
>>> Please continue to test! Thank you for your help :)
>>>
>>
>>
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
>
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>

--
http://ruedigergad.com

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

dmesg_with_X11.out (97K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
PPS:
Sorry, the second attachment got removed again.
Trying once more to send the Xorg.log.
Does the list only allow one attachment per e-mail?




On 18.10.2015 11:18, Ruediger Gad wrote:

> PS:
> Please excuse the noise.
> Just another update:
> Thanks to the hint of Arto, I tried once more with external screens
> attached to all outputs (VGA & HDMI).
>
> After kldload i915kms, the internal display turns off and the external
> screens turn on.
> In the console, I can see some red stripes at the top similar to what
> Rob mentioned.
> Starting X works and I can see the output on the external screens but
> the internal screen remains black.
> I can also change the resolution etc. via xrandr but, so far, I did not
> manage to turn the internal display on.
>
> Attached, I send a the Xorg.log and another dmesg output that was taken
> while running X.
>
> Again, thanks a lot for the work.
>
>
>
> BR,
>
> Ruediger
>
>
>
>
> On 17.10.2015 21:38, Ruediger Gad wrote:
>> Sorry, the second attachment got somehow removed.
>> I'm giving it another try as "dmesg.sc.out".
>>
>>
>>
>>
>> On 17.10.2015 21:15, Ruediger Gad wrote:
>>> Hi,
>>>
>>> thank you very much for your work on this.
>>>
>>> I tried the latest version as of today (commit
>>> 382004782ca4960f1e25a890e8df21507ba9eb4f).
>>> Unfortunately, it does not seem to work as I only get a black screen on
>>> the console.
>>>
>>> I tried with both kern.vty="vt" and kern.vty="sc".
>>> Attached, I send the corresponding dmesg output for vt (dmesg.out) and
>>> sc (dmesg.out.sc).
>>> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
>>> I hope the dmesg out is helpful.
>>>
>>> Again, thank you very very much for working on this.
>>>
>>>
>>>
>>> BR,
>>>
>>> Ruediger
>>>
>>>
>>>
>>>
>>> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
>>>> Hi!
>>>>
>>>> Lately, I fixed several issues with the GEM, people already reported
>>>> this improved things for them.
>>>>
>>>> I believe I fixed two problems with the output connectors too and I hope
>>>> that it will be fine now for people who reported eg. non-working HDMI.
>>>> However, I can't test this myself.
>>>>
>>>> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>>>>
>>>> As a reminder, informations are available on the wiki:
>>>> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>>>>
>>>> Please continue to test! Thank you for your help :)
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> [hidden email] mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>> To unsubscribe, send any mail to "[hidden email]"
>>>
>>
>>
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
>
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>


--
http://ruedigergad.com
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
The problem seems to be the file name.
Trying once more with a different file name.
In addition, to avoid further noise, I also put the log on pastebin:
http://pastebin.com/XqS8zwyZ




On 18.10.2015 11:31, Ruediger Gad wrote:

> PPS:
> Sorry, the second attachment got removed again.
> Trying once more to send the Xorg.log.
> Does the list only allow one attachment per e-mail?
>
>
>
>
> On 18.10.2015 11:18, Ruediger Gad wrote:
>> PS:
>> Please excuse the noise.
>> Just another update:
>> Thanks to the hint of Arto, I tried once more with external screens
>> attached to all outputs (VGA & HDMI).
>>
>> After kldload i915kms, the internal display turns off and the external
>> screens turn on.
>> In the console, I can see some red stripes at the top similar to what
>> Rob mentioned.
>> Starting X works and I can see the output on the external screens but
>> the internal screen remains black.
>> I can also change the resolution etc. via xrandr but, so far, I did not
>> manage to turn the internal display on.
>>
>> Attached, I send a the Xorg.log and another dmesg output that was taken
>> while running X.
>>
>> Again, thanks a lot for the work.
>>
>>
>>
>> BR,
>>
>> Ruediger
>>
>>
>>
>>
>> On 17.10.2015 21:38, Ruediger Gad wrote:
>>> Sorry, the second attachment got somehow removed.
>>> I'm giving it another try as "dmesg.sc.out".
>>>
>>>
>>>
>>>
>>> On 17.10.2015 21:15, Ruediger Gad wrote:
>>>> Hi,
>>>>
>>>> thank you very much for your work on this.
>>>>
>>>> I tried the latest version as of today (commit
>>>> 382004782ca4960f1e25a890e8df21507ba9eb4f).
>>>> Unfortunately, it does not seem to work as I only get a black screen on
>>>> the console.
>>>>
>>>> I tried with both kern.vty="vt" and kern.vty="sc".
>>>> Attached, I send the corresponding dmesg output for vt (dmesg.out) and
>>>> sc (dmesg.out.sc).
>>>> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
>>>> I hope the dmesg out is helpful.
>>>>
>>>> Again, thank you very very much for working on this.
>>>>
>>>>
>>>>
>>>> BR,
>>>>
>>>> Ruediger
>>>>
>>>>
>>>>
>>>>
>>>> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
>>>>> Hi!
>>>>>
>>>>> Lately, I fixed several issues with the GEM, people already reported
>>>>> this improved things for them.
>>>>>
>>>>> I believe I fixed two problems with the output connectors too and I hope
>>>>> that it will be fine now for people who reported eg. non-working HDMI.
>>>>> However, I can't test this myself.
>>>>>
>>>>> I'm still chasing a problem with Mesa (Stellarium hangs on startup for me).
>>>>>
>>>>> As a reminder, informations are available on the wiki:
>>>>> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>>>>>
>>>>> Please continue to test! Thank you for your help :)
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> [hidden email] mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>>> To unsubscribe, send any mail to "[hidden email]"
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> [hidden email] mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>> To unsubscribe, send any mail to "[hidden email]"
>>>
>>
>>
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "[hidden email]"
>>
>
>

--
http://ruedigergad.com

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"

Xorg.0.log.out (21K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Mehmet Erol Sanliturk
In reply to this post by Ruediger Gad
On Sun, Oct 18, 2015 at 2:31 AM, Ruediger Gad <[hidden email]> wrote:

> PPS:
> Sorry, the second attachment got removed again.
> Trying once more to send the Xorg.log.
> Does the list only allow one attachment per e-mail?
>
>
>
>
> On 18.10.2015 11:18, Ruediger Gad wrote:
> > PS:
> > Please excuse the noise.
> > Just another update:
> > Thanks to the hint of Arto, I tried once more with external screens
> > attached to all outputs (VGA & HDMI).
> >
> > After kldload i915kms, the internal display turns off and the external
> > screens turn on.
>



In some mother boards , it is explicitly written that "when a graphic card
is attached , main board video ports are disabled" .

If you check manual of your computer , it is likely that there will be an
explanation about effect of additional monitors .


Mehmet Erol Sanliturk




> > In the console, I can see some red stripes at the top similar to what
> > Rob mentioned.
> > Starting X works and I can see the output on the external screens but
> > the internal screen remains black.
> > I can also change the resolution etc. via xrandr but, so far, I did not
> > manage to turn the internal display on.
> >
> > Attached, I send a the Xorg.log and another dmesg output that was taken
> > while running X.
> >
> > Again, thanks a lot for the work.
> >
> >
> >
> > BR,
> >
> > Ruediger
> >
> >
> >
> >
> > On 17.10.2015 21:38, Ruediger Gad wrote:
> >> Sorry, the second attachment got somehow removed.
> >> I'm giving it another try as "dmesg.sc.out".
> >>
> >>
> >>
> >>
> >> On 17.10.2015 21:15, Ruediger Gad wrote:
> >>> Hi,
> >>>
> >>> thank you very much for your work on this.
> >>>
> >>> I tried the latest version as of today (commit
> >>> 382004782ca4960f1e25a890e8df21507ba9eb4f).
> >>> Unfortunately, it does not seem to work as I only get a black screen on
> >>> the console.
> >>>
> >>> I tried with both kern.vty="vt" and kern.vty="sc".
> >>> Attached, I send the corresponding dmesg output for vt (dmesg.out) and
> >>> sc (dmesg.out.sc).
> >>> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
> >>> I hope the dmesg out is helpful.
> >>>
> >>> Again, thank you very very much for working on this.
> >>>
> >>>
> >>>
> >>> BR,
> >>>
> >>> Ruediger
> >>>
> >>>
> >>>
> >>>
> >>> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
> >>>> Hi!
> >>>>
> >>>> Lately, I fixed several issues with the GEM, people already reported
> >>>> this improved things for them.
> >>>>
> >>>> I believe I fixed two problems with the output connectors too and I
> hope
> >>>> that it will be fine now for people who reported eg. non-working HDMI.
> >>>> However, I can't test this myself.
> >>>>
> >>>> I'm still chasing a problem with Mesa (Stellarium hangs on startup
> for me).
> >>>>
> >>>> As a reminder, informations are available on the wiki:
> >>>>
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
> >>>>
> >>>> Please continue to test! Thank you for your help :)
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> [hidden email] mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> >>> To unsubscribe, send any mail to "[hidden email]"
> >>>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> [hidden email] mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> >> To unsubscribe, send any mail to "[hidden email]"
> >>
> >
> >
> >
> >
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> > To unsubscribe, send any mail to "[hidden email]"
> >
>
>
> --
> http://ruedigergad.com
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Koop Mast-2
In reply to this post by Gary Jennejohn-6


On 18/10/2015 08:41, Gary Jennejohn wrote:

> On Sun, 18 Oct 2015 03:05:25 +0300
> Arto Pekkanen <[hidden email]> wrote:
>
>> I managed to work around this problem with the following command (as
>> root):
>> # chgrp wheel /dev/dri/*
>>
> You can more easily fix this by setting the owner, e.g. root:wheel,
> in /etc/devfs.conf.  You probably need an entry for each device
> which can appear under /dev/dri.  See devfs.conf(5).
>
I can't find the original problem, but in CURRENT the /dev/dri/* devices
are given root:video permissions. This is still root:wheel on older
FreeBSD versions. So the only thing you have to do is add the video
group to your user.

# pw groupmod video -m jru

-Koop

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Matthew D. Fuller
In reply to this post by Arto Pekkanen
On Sun, Oct 18, 2015 at 04:37:59AM +0300 I heard the voice of
Arto Pekkanen, and lo! it spake thus:
>
> When I use SNA acceleration, I can get OpenGL applications to work
> without core dumping.
>
> However, when I use UXA acceleration instead [...]

I'm under the vague impression that SNA is The Chosen Way upstream for
Intel, and so should is all that could be expected to work.


--
Matthew Fuller     (MF4839)   |  [hidden email]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new i915 driver (rev. 3820047)

Ruediger Gad
In reply to this post by Mehmet Erol Sanliturk
Thanks for the reply.

My computer is a laptop.
With "internal" screen, I was referring to the main screen of the laptop.
The "external" screens are the ones attached via the VGA respectively
HDMI ports of the laptop.
All video ports, internal and external, are connected to the same
graphics chip(s).

The laptop actually has a "dual" graphics chip configuration with an
Intel and an Nvidia graphics chip.
However, I strongly assume that my issues are not related to this dual
chip configuration because I see the output on the external screens and,
as far as I know, a mixed operation of the graphic chips (in which one
chip drives one display and the other chip drives another display) is
not possible.
This is also reported accordingly in the Xorg.log (it says something
about ".. no multi-card support").

To me it seems like that, for some reason, the internal video port is
not properly enabled.
You can see, e.g., in the Xorg.log that the internal screen (the one
with the 2560x1440 resolution) gets detected, EDID values are read, etc.
xrandr also reports the internal video port to be enabled but no picture
is shown.
I can also change the video configuration via xrandr and see the effects
on the external screen but the internal screen stays black.



BR,

Ruediger




On 18.10.2015 11:42, Mehmet Erol Sanliturk wrote:

>
>
> On Sun, Oct 18, 2015 at 2:31 AM, Ruediger Gad <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     PPS:
>     Sorry, the second attachment got removed again.
>     Trying once more to send the Xorg.log.
>     Does the list only allow one attachment per e-mail?
>
>
>
>
>     On 18.10.2015 11:18, Ruediger Gad wrote:
>     > PS:
>     > Please excuse the noise.
>     > Just another update:
>     > Thanks to the hint of Arto, I tried once more with external screens
>     > attached to all outputs (VGA & HDMI).
>     >
>     > After kldload i915kms, the internal display turns off and the external
>     > screens turn on.
>
>
>
>
> In some mother boards , it is explicitly written that "when a graphic
> card is attached , main board video ports are disabled" .
>
> If you check manual of your computer , it is likely that there will be
> an explanation about effect of additional monitors .
>
>
> Mehmet Erol Sanliturk
>
>
>  
>
>     > In the console, I can see some red stripes at the top similar to what
>     > Rob mentioned.
>     > Starting X works and I can see the output on the external screens but
>     > the internal screen remains black.
>     > I can also change the resolution etc. via xrandr but, so far, I
>     did not
>     > manage to turn the internal display on.
>     >
>     > Attached, I send a the Xorg.log and another dmesg output that was
>     taken
>     > while running X.
>     >
>     > Again, thanks a lot for the work.
>     >
>     >
>     >
>     > BR,
>     >
>     > Ruediger
>     >
>     >
>     >
>     >
>     > On 17.10.2015 21:38, Ruediger Gad wrote:
>     >> Sorry, the second attachment got somehow removed.
>     >> I'm giving it another try as "dmesg.sc.out".
>     >>
>     >>
>     >>
>     >>
>     >> On 17.10.2015 21:15, Ruediger Gad wrote:
>     >>> Hi,
>     >>>
>     >>> thank you very much for your work on this.
>     >>>
>     >>> I tried the latest version as of today (commit
>     >>> 382004782ca4960f1e25a890e8df21507ba9eb4f).
>     >>> Unfortunately, it does not seem to work as I only get a black
>     screen on
>     >>> the console.
>     >>>
>     >>> I tried with both kern.vty="vt" and kern.vty="sc".
>     >>> Attached, I send the corresponding dmesg output for vt
>     (dmesg.out) and
>     >>> sc (dmesg.out.sc <http://dmesg.out.sc>).
>     >>> My system is a laptop with an i7-4710MQ CPU and a 2560x1440 display.
>     >>> I hope the dmesg out is helpful.
>     >>>
>     >>> Again, thank you very very much for working on this.
>     >>>
>     >>>
>     >>>
>     >>> BR,
>     >>>
>     >>> Ruediger
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> On 17.10.2015 15:26, Jean-Sébastien Pédron wrote:
>     >>>> Hi!
>     >>>>
>     >>>> Lately, I fixed several issues with the GEM, people already
>     reported
>     >>>> this improved things for them.
>     >>>>
>     >>>> I believe I fixed two problems with the output connectors too
>     and I hope
>     >>>> that it will be fine now for people who reported eg.
>     non-working HDMI.
>     >>>> However, I can't test this myself.
>     >>>>
>     >>>> I'm still chasing a problem with Mesa (Stellarium hangs on
>     startup for me).
>     >>>>
>     >>>> As a reminder, informations are available on the wiki:
>     >>>>
>     https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8
>     >>>>
>     >>>> Please continue to test! Thank you for your help :)
>     >>>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> [hidden email] <mailto:[hidden email]> mailing
>     list
>     >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     >>> To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>     >>>
>     >>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> [hidden email] <mailto:[hidden email]> mailing list
>     >> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     >> To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>     >>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > [hidden email] <mailto:[hidden email]> mailing list
>     > https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     > To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>     >
>
>
>     --
>     http://ruedigergad.com
>     _______________________________________________
>     [hidden email] <mailto:[hidden email]> mailing list
>     https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>
>


--
http://ruedigergad.com
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
12