Re: RC4 still gives me trouble with i915

2024-02-09 Thread Jörn Clausen
According to Xorg.log, this is the chip:

[53.369] (II) intel(0): SNA initialized with Baytrail (gen7) backend

Just in case there are some helpful information, these are all the lines
from the intel driver:

[53.319] (II) intel(0): Using Kernel Mode Setting driver: i915, version
1.6.0 20200114
[53.322] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD
Graphics
[53.322] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2;
using a maximum of 2 threads
[53.322] (II) intel(0): Creating default Display subsection in Screen
section
[53.322] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[53.322] (==) intel(0): RGB weight 888
[53.322] (==) intel(0): Default visual is TrueColor
[53.338] (II) intel(0): Output VGA1 has no monitor section
[53.340] (II) intel(0): Enabled output VGA1
[53.340] (II) intel(0): Output DP1 has no monitor section
[53.340] (II) intel(0): Enabled output DP1
[53.340] (II) intel(0): Output HDMI1 has no monitor section
[53.340] (II) intel(0): Enabled output HDMI1
[53.340] (--) intel(0): Using a maximum size of 256x256 for hardware
cursors
[53.340] (II) intel(0): Output VIRTUAL1 has no monitor section
[53.340] (II) intel(0): Enabled output VIRTUAL1
[53.340] (--) intel(0): Output VGA1 using initial mode 1280x1024 on
pipe 0
[53.340] (==) intel(0): TearFree enabled
[53.340] (==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
[53.340] (==) intel(0): DPI set to (96, 96)
[53.369] (II) intel(0): SNA initialized with Baytrail (gen7) backend
[53.369] (==) intel(0): Backing store enabled
[53.369] (==) intel(0): Silken mouse enabled
[53.372] (II) intel(0): HW Cursor enabled
[53.389] (==) intel(0): DPMS enabled
[53.398] (II) intel(0): [DRI2] Setup complete
[53.398] (II) intel(0): [DRI2]   DRI driver: i965
[53.398] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[53.398] (II) intel(0): direct rendering: DRI2 enabled
[53.691] (II) intel(0): switch to mode 1280x1024@60.0 on VGA1 using
pipe 0, position (0, 0), rotation normal, reflection none
[53.699] (II) intel(0): Setting screen physical size to 338 x 270


On Thu, Feb 8, 2024 at 10:01 PM Mike Pumford 
wrote:

>
>
> On 08/02/2024 16:08, Jörn Clausen wrote:
> > Hello!
> >
> > For the last RCs, I've tested the live image for amd64 on my desktop
> > machine, that has been running 9.x with X for years now. Whenever I
> > start X11, either via "startx" or "/etc/rc.d/xdm onestart", the display
> > gets unusable. I see fragments of ctwm and an Xterm in the first case,
> > and parts of the login display in the second, but the sessions are
> > otherwise broken.
> >
> > Is this expected behaviour with the live image, or should the correct
> > configuration get picked up? I see no warning in the Xorg.log,
> > everything seems to get detected fine. Please let me know if someone
> > needs debug information beyond the following:
> >
> > The CPU is
> >
> > cpu0: "Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz"
> > cpu0: Intel Atom E3000, Z3[67]00 (686-class), 2000.22 MHz
> > cpu0: family 0x6 model 0x37 stepping 0x8 (id 0x30678)
> >
> > These are some parts from the messages log:
> >
> > [ 5.009976] [drm] Supports vblank timestamp caching Rev 2
> (21.10.2013).
> > [ 5.009976] [drm] Driver supports precise vblank timestamp query.
> > [ 5.009976] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0)
> > [ 5.079724] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on
> > minor 0
> > [ 5.099724] intelfb0 at i915drmkms0
> > [ 5.099724] [drm] DRM_I915_DEBUG enabled
> > [ 5.099724] [drm] DRM_I915_DEBUG_GEM enabled
> > [ 5.099724] intelfb0: framebuffer at 0xc002, size 1280x1024,
> > depth 32, stride 5120
> >
> I had a similar problem but the fix that resolved it for me went in just
> before RC3 so RC4 should have it.
>
> However I do know it didn't fix the issue for everyone as it depends
> just exactly what Intel display chip you have. If you can grap the
> /var/log/Xorg.log output that often identifies the chip. Mine for
> example says:
>
> [361580.187] (II) intel(0): SNA initialized with Haswell (gen7.5, gt2)
> backend
>
> This is with the intel driver. The modesetting driver which is the
> alternative is less helpful in this respect.
>
> Mike
>


-- 
Joern Clausen
https://www.oe-files.de/photography/


Re: Raspberry Pi Zero W almost useless

2024-02-09 Thread Michael
Hello,

On Fri, 9 Feb 2024 06:25:56 +0100
Ramiro Aceves  wrote:

> >> I have also the same problem that I had with the chineese 8188FTV,  as
> >> soon I connect it to the raspberry pi it reboots inmediately. In the
> >> next reboot it works fine. It occurs the same in another Zero W that I
> >> own  with Raspbian and a different power supply. So I doubt that the
> >> culprit is the power supply. The Zero W seems to be a very flaky device
> >> in terms of power supply.
> >>  
> > A powered hub should fix that, when a device is plugged directly into the
> > raspberry pis usb (IIRC only 300mA is available) it can cause reboots.
> >   
> 
> Oh yes, that would be a right technical fix for the problem but it's a 
> bit of an aberration in terms of cost and size to use a powered HUB with 
> its own power supply to fix a little thing like the ZeroW, you know ;-)

Just use the hub to power the Pi. I used to do that wit the Pi1 and 2.

have fun
Michael


Re: Raspberry Pi Zero W almost useless

2024-02-09 Thread Michael van Elst
ea1...@gmail.com (Ramiro Aceves) writes:

>Oh yes, that would be a right technical fix for the problem but it's a 
>bit of an aberration in terms of cost and size to use a powered HUB with 
>its own power supply to fix a little thing like the ZeroW, you know ;-)

RPI0-3 models all have issues with power.

Especially on the original RPI1 and RPI0 variants you shouldn't
consider USB as being "hot pluggable". For the other models
hot-plugging low power USB devices (i.e. using 100mA or less)
should be fine. Unfortunately that might rule out things like
many gaming keyboards and also some WLAN dongles.