Bug#1023780: spirv-tools: not multi-arch compatible

[Witold Baryluk]

Package: spirv-tools
Version: 2022.4-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

spirv-tools package provide in one package, binaries, libraries, headers,
cmake files and pkg-config files.

For cross compiling rusticl in Mesa for example one needs spirv-tools.

But it is not possible to have both i386 and amd64 of
lib/header/pkg-config files for spirv-tools installed.

Consider splitting package into spirv-tools, libspirv-tools,
libspirv-tools-dev, and make lib* ones coninstallable (or for header
files same).

Regards,
Witold


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-rc3 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages spirv-tools depends on:
ii  libc6   2.36-4
ii  libstdc++6  12.2.0-9

spirv-tools recommends no packages.

spirv-tools suggests no packages.

-- no debconf information

Bug#987768: libxext-dev depends on transitional packages

[Witold Baryluk]

True.

Already reported here https://bugs.debian.org/969068

Regards,
Witold


On Thu, 29 Apr 2021, 10:45 Laurent Bigonville,  wrote:

> Package: libxext-dev
> Version: 2:1.3.3-1.1
> Severity: normal
>
> Hello,
>
> libxext-dev depends on the following transitional packages:
>
> - x11proto-core-dev
> - x11proto-xext-dev
>
> Both can be replaced apparently by just a dependency on x11proto-dev
>
> Kind regards,
> Laurent Bigonville
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_BE:fr
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
>
> Versions of packages libxext-dev depends on:
> ii  libx11-dev2:1.7.0-2
> ii  libxext6  2:1.3.3-1.1
> ii  x11proto-core-dev 2020.1-1
> ii  x11proto-dev [x11proto-xext-dev]  2020.1-1
> ii  x11proto-xext-dev 2020.1-1
>
> libxext-dev recommends no packages.
>
> Versions of packages libxext-dev suggests:
> pn  libxext-doc  
>
> -- no debconf information
>
>

Re: [Git][xorg-team/lib/mesa][debian-unstable] rules: Disable vulkan swrast, it's getting used instead of the native driver.

[Witold Baryluk]

Ack. I agree with all what you wrote.


On Fri, 8 Jan 2021 at 14:58, Michel Dänzer  wrote:
>
> On 2021-01-08 11:22 a.m., Witold Baryluk wrote:
> > True, that a lot of applications don't properly inspect physical devices 
> > list.
> > (I do have some patches to various tools and examples to fix it,
> > they are already in review by respective projects).
>
> Thanks for doing that, though I'm afraid it's a game of whack-a-mole.
>
>
> > And it is also correct, that the order might be somehow random,
> > i.e. depended on file system readdir entries order.
> >
> > However, Mesa's device_selection layer (enabled implicitly and 
> > automatically),
> > will preferentially re-order devices, and that makes all apps
> > by default that are not smart about it, use non-CPU devices.
> > Lavapipe will always be considered last.
>
> On my development machine, vulkaninfo lists these devices:
>
> GPU id : 0 (AMD RADV NAVI14 (ACO)):
>
> GPU id : 1 (llvmpipe (LLVM 11.0.1, 256 bits)):
>
> GPU id : 2 (AMD RADV NAVI14 (ACO)):
>
> GPU id : 3 (llvmpipe (LLVM 12.0.0, 256 bits)):
>
>
> Devices 0 & 1 are from /usr/share/vulkan/icd.d/ (the mesa-vulkan-drivers
> package), devices 2 & 3 are from /usr/local/share/vulkan/icd.d/ (my
> local Mesa build).
>
> Now imagine a system where the GPU isn't supported by the packaged
> drivers yet, but a developer is working on adding that support. It looks
> like this could result in lavapipe from the system packages getting
> preferred over the local-built HW driver.
>
> Addressing this might require changes to the Vulkan loader, which should
> allow addressing these issues completely without the Mesa
> device_selection layer.
>
> (In this particular scenario, just enumerating devices from
> /usr/local/share/vulkan/icd.d/ before /usr/share/vulkan/icd.d/ should be
> enough, which I'd argue should be done anyway :)
>
>
> > The displayed warning was just in the wrong place, it is displayed
> > even if lavapipe is not used, merely instantiated for device enumeration,
> > which is wrong. Patch to fix this is trivial, and already in review 
> > upstream:
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8377
>
> Thanks, that should prevent a lot of confusion.
>
>
> There's still at least one other case where shipping lavapipe could be
> an issue: If a system didn't have any Vulkan support before (e.g.
> because the GPU is too old for Vulkan support), it could now start using
> lavapipe. I suspect this is what's going on in Fedora bug reports such
> as https://bugzilla.redhat.com/show_bug.cgi?id=1912159 "pidgin crashes
> with mesa-vulkan-drivers-20.3.2-1.fc33".
>
>
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer

Re: [Git][xorg-team/lib/mesa][debian-unstable] rules: Disable vulkan swrast, it's getting used instead of the native driver.

[Witold Baryluk]

True, that a lot of applications don't properly inspect physical devices list.
(I do have some patches to various tools and examples to fix it,
they are already in review by respective projects).
And it is also correct, that the order might be somehow random,
i.e. depended on file system readdir entries order.

However, Mesa's device_selection layer (enabled implicitly and automatically),
will preferentially re-order devices, and that makes all apps
by default that are not smart about it, use non-CPU devices.
Lavapipe will always be considered last.

The displayed warning was just in the wrong place, it is displayed
even if lavapipe is not used, merely instantiated for device enumeration,
which is wrong. Patch to fix this is trivial, and already in review upstream:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8377


Thanks Timo and Michel, for chiming in.

On Thu, 7 Jan 2021 at 16:34, Michel Dänzer  wrote:
>
> On 2021-01-07 3:54 p.m., Witold Baryluk wrote:
> > That is weird. I have no issues at all. radv is loaded for me by
> > default in essentially all apps.
>
> The fundamental issue is that the Vulkan loader doesn't define any
> particular order in which it enumerates Vulkan devices; it currently at
> least partially depends on the order in which the filesystem enumerates
> the *_icd..json files. This means that lavapipe may end up being
> enumerated before or after HW accelerated devices depending on the
> current state of the filesystem, which may change with modifications to
> the directory containing those files.
>
> Applications generally just use the first enumerated device by default,
> without checking if it's HW accelerated or not.
>
>
> > On Thu, 7 Jan 2021 at 14:23, Timo Aaltonen  wrote:
> >>
> >> On 7.1.2021 13.22, Witold Baryluk wrote:
> >>> Hi Timo.
> >>>
> >>> Do you know what apps is this happening with that causes problems?
> >>> lavapipe does expose itself as DEVICE_TYPE_CPU, but it is likely
> >>> some apps don't inspect the type properly. Would be interesting
> >>> know which these are to investigate it properly.
> >>>
> >>> Of course, it can be solve with the VK_LAYER_MESA_device_select
> >>> but also obviously we can't make every user need to use it.
> >>>
> >>> Maybe a better option is to package swrast into a own package?
> >>>
> >>> mesa-vulkan-swrast-driver?
> >>>
> >>> Thanks.
> >>
> >> Hi, according to irc everything (starting from vkinfo, vkcube), so we
> >> can't ship it. And doing a separate package doesn't sound like a good
> >> idea, loader/mesa just need to be fixed.
> >>
> >>
> >> --
> >> t
> >
>
>
> --
> Earthling Michel Dänzer   |   https://redhat.com
> Libre software enthusiast | Mesa and X developer

Re: [Git][xorg-team/lib/mesa][debian-unstable] rules: Disable vulkan swrast, it's getting used instead of the native driver.

[Witold Baryluk]

BTW.

The "WARNING: lavapipe is not a conformant vulkan implementation,
testing use only."
message emitted by Mesa, doesn't mean that lavapipe is actually used by the app.
It just means it was loaded, which is required for device enumeration.
Not that it was actually selected and in use.


On Thu, 7 Jan 2021 at 14:54, Witold Baryluk  wrote:
>
> That is weird. I have no issues at all. radv is loaded for me by
> default in essentially all apps.
>
> On Thu, 7 Jan 2021 at 14:23, Timo Aaltonen  wrote:
> >
> > On 7.1.2021 13.22, Witold Baryluk wrote:
> > > Hi Timo.
> > >
> > > Do you know what apps is this happening with that causes problems?
> > > lavapipe does expose itself as DEVICE_TYPE_CPU, but it is likely
> > > some apps don't inspect the type properly. Would be interesting
> > > know which these are to investigate it properly.
> > >
> > > Of course, it can be solve with the VK_LAYER_MESA_device_select
> > > but also obviously we can't make every user need to use it.
> > >
> > > Maybe a better option is to package swrast into a own package?
> > >
> > > mesa-vulkan-swrast-driver?
> > >
> > > Thanks.
> >
> > Hi, according to irc everything (starting from vkinfo, vkcube), so we
> > can't ship it. And doing a separate package doesn't sound like a good
> > idea, loader/mesa just need to be fixed.
> >
> >
> > --
> > t

Re: [Git][xorg-team/lib/mesa][debian-unstable] rules: Disable vulkan swrast, it's getting used instead of the native driver.

[Witold Baryluk]

That is weird. I have no issues at all. radv is loaded for me by
default in essentially all apps.

On Thu, 7 Jan 2021 at 14:23, Timo Aaltonen  wrote:
>
> On 7.1.2021 13.22, Witold Baryluk wrote:
> > Hi Timo.
> >
> > Do you know what apps is this happening with that causes problems?
> > lavapipe does expose itself as DEVICE_TYPE_CPU, but it is likely
> > some apps don't inspect the type properly. Would be interesting
> > know which these are to investigate it properly.
> >
> > Of course, it can be solve with the VK_LAYER_MESA_device_select
> > but also obviously we can't make every user need to use it.
> >
> > Maybe a better option is to package swrast into a own package?
> >
> > mesa-vulkan-swrast-driver?
> >
> > Thanks.
>
> Hi, according to irc everything (starting from vkinfo, vkcube), so we
> can't ship it. And doing a separate package doesn't sound like a good
> idea, loader/mesa just need to be fixed.
>
>
> --
> t

Re: [Git][xorg-team/lib/mesa][debian-unstable] rules: Disable vulkan swrast, it's getting used instead of the native driver.

[Witold Baryluk]

Hi Timo.

Do you know what apps is this happening with that causes problems?
lavapipe does expose itself as DEVICE_TYPE_CPU, but it is likely
some apps don't inspect the type properly. Would be interesting
know which these are to investigate it properly.

Of course, it can be solve with the VK_LAYER_MESA_device_select
but also obviously we can't make every user need to use it.

Maybe a better option is to package swrast into a own package?

mesa-vulkan-swrast-driver?

Thanks.

On Wed, 6 Jan 2021 at 10:21, Timo Aaltonen  wrote:

> Timo Aaltonen pushed to branch debian-unstable at X Strike Force / lib /
> mesa  Commits:
>
>- *74651ecd
>
> *
>by Timo Aaltonen *at 2021-01-06T12:05:04+02:00*
>
>rules: Disable vulkan swrast, it's getting used instead of the native 
> driver.
>
>
> 2 changed files:
>
>- debian/changelog
><#m_4877593938721081832_9c96da0e9f91d7d8937b69b524702c106258f0d1>
>- debian/rules
><#m_4877593938721081832_8756c63497c8dc39f7773438edf53b220c773f67>
>
> Changes:
>
>- *debian/changelog*
>
> 
>--
>1 1
>
> mesa (20.3.2-2) UNRELEASED; urgency=medium
>
>2 2
>
>  3 3
>
>   * path_max.diff: Updated.
>
>4
>
>+  * rules: Disable vulkan swrast, it's getting used instead of the
>
>5
>
>+native driver.
>
>4 6
>
>  5 7
>
>  -- Timo Aaltonen   Mon, 04 Jan 2021 09:07:25 +0200
>
>6 8
>
>
>- *debian/rules*
>
> 
>--
>... ... @@ -55,7 +55,7 @@ else
>55 55
>
>   # radv/lavapipe needs LLVM and the Vulkan loader, so only build on the 
> subset of
>
>56 56
>
>   # arches where we have LLVM enabled and where the Vulkan loader is 
> built.
>
>57 57
>
>   ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 
> mips64el mipsel powerpc ppc64 ppc64el s390x sparc64))
>
>58
>
>-  VULKAN_DRIVERS += amd swrast
>
>58
>
>+  VULKAN_DRIVERS += amd
>
>59 59
>
>   endif
>
>60 60
>
>  61 61
>
>   ifeq ($(DEB_HOST_ARCH_OS), linux)
>
>
>
> —
> View it on GitLab
> .
>
> You're receiving this email because of your account on salsa.debian.org.
> If you'd like to receive fewer emails, you can adjust your notification
> settings.
>

Bug#978049: vulkan-tools: Vulkan not usable by default on AMD hardware

[Witold Baryluk]

Hi Ian.

This is not a bug in vulkan-tools. vulkan-tools correctly reports
initialization failure, as it should.

It is pretty well known fact that HD 7900 series requires switching to
amdgpu from radeontop for Vulkan support.

It is documented on Debian wiki:
https://wiki.debian.org/AtiHowTo#AMDGPU.2FVulkan_on_older_cards

Unless upstream Linux kernel fixes this to make amdgpu a default for
this hardware
(which could happen very soon, after years of waiting!), Debian can't really
(and shouldn't) do much about it.

Please close this bug.


On Fri, 25 Dec 2020 at 05:57, Ian Bruce  wrote:
>
> Package: vulkan-tools
> Version: 1.2.154.0+dfsg1-1
> Severity: important
>
>
> # vulkaninfo
> ERROR at /build/vulkan-tools-tihVv9/vulkan-
> tools-1.2.154.0+dfsg1/vulkaninfo/vulkaninfo.h:248:vkEnumerateInstanceExtensionProperties
> failed with ERROR_INITIALIZATION_FAILED
>
>
> a google search finds this page --
>
> https://bbs.archlinux.org/viewtopic.php?id=254015
>
> -- which suggests that the root problem is that the wrong kernel module is
> getting loaded.
> and so it turns out to be:
>
>
> # lspci -k
> ...
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280]
> Subsystem: Hightech Information System Ltd. Tahiti PRO [Radeon HD
> 7950/8950 OEM / R9 280]
> Kernel driver in use: radeon
> Kernel modules: radeon, amdgpu
>
>
> it doesn't seem reasonable that end users should have to figure this out, and
> edit
> the mkinitramfs config files, or whatever, to get this to work. can't it be
> arranged
> that the amdgpu kernel module is preferred over the radeon kernel module,
> whenever
> AMD GCN video hardware is detected?
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
> (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages vulkan-tools depends on:
> ii  libc6   2.31-5
> ii  libgcc-s1   10.2.1-1
> ii  libstdc++6  10.2.1-1
> ii  libvulkan1  1.2.154.1-1
> ii  libwayland-client0  1.18.0-2~exp1.1
> ii  libx11-62:1.6.12-1
> ii  libxcb1 1.14-2
>
> vulkan-tools recommends no packages.
>
> vulkan-tools suggests no packages.
>
> -- no debconf information
>

Bug#972736: FTBFS Mesa 20.2.x fails to build on x32 (debian\rules issue)

[Witold Baryluk]

Source: mesa
Followup-For: Bug #972736
X-Debbugs-Cc: witold.bary...@gmail.com

I think a better approach, would be to use a trailing comms in the list

"-Dvulkan-drivers=['amd','swrast',]"

Does work. So doing:

VULKAN_DRIVERS += 'intel',

"-Dvulkan-drivers=[$(VULKAN_DRIVERS)]"

would probably work. It requires each element of the list to be single quotes.



Even nicer is just to use some Makefile magic, to convert list of words
into ones with single quotes, then to convert spaces into commas.

VULKAN_DRIVERS += amd
VULKAN_DRIVERS += intel
VULKAN_DRIVERS += swrast

empty:=
space := $(empty) $(empty)
comma := ,
VULKAN_DRIVERS := $(patsubst %,'%',$(VULKAN_DRIVERS))
VULKAN_DRIVERS_LIST := $(subst $(space),$(comma),$(VULKAN_DRIVERS))

test:
echo "[$(VULKAN_DRIVERS_LIST)]"


$ make -s test
['amd','intel','swrast']
$

for empty list it give me this:
$ make -s test
[]
$

Sweet!

Maybe there is some shared function for Debian rules that already
implement this for reuse.


Cheers,
Witold

Bug#975679: mesa-vulkan-drivers: Include v3dv on arm. Include zink on arm and ppc.

[Witold Baryluk]

Package: mesa-vulkan-drivers
Version: 20.2.2-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

Mesa 2.2.0 has v3dv Vulkan driver in stable condition, and it just passed
official Khronos confornmance tests for Vulkan 1.0.

I would suggest enabling v3dv vulkan driver on arm64 so it can be used
easily.

It should work on armel and armhf too, and it probably makes sense to
enable it there too. However upstream Mesa CI / CD pipelines only do
builds and tests on arm64.


I would also suggest changing the current restriction of zink to be
expanded to all architectures where there is any Vulkan loader or AMD
Vulkan driver. Currently zink is restricted to be build on amd64, i386
and x32, which is unecassary restriction.

zink should be build additionally on arm64 armel armhf mips64el mipsel
powerpc ppc64 ppc64el s390x sparc64, and possible more (i.e. alpha, hppa,
m68k, sparc64, riscv64), as all of them do have vulkan loaders,
validation layers, and together with `lavapipe` technically vulkan can be
used on all archs that do have LLVM support in some way or form.
In the future zink should also be able to wrok with non-Mesa Vulkan
implementation.



Thank you!


Regards,
Witold

Bug#969068: libxinerama-dev depends on transitional package x11proto-xinerama-dev

[Witold Baryluk]

Package: libxinerama-dev
Version: 2:1.1.4-2
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

libxinerama-dev depends on transitional package x11proto-xinerama-dev.

Please depend on x11proto-dev (with "> 2018.3" version condition if
needed) instead.



Similar applies to some other packages, like:

libxxf86vm-dev depends on transitional package x11proto-xf86vidmode-dev,
but should depend now on x11proto-dev instead.

libxss-dev depends on transitional package x11proto-scrnsaver-dev,
but should depend now on x11proto-dev instead.

libxtst-dev depends on transitional package x11proto-record-dev,
but should depend now on x11proto-dev instead.

libxi-dev depends on transitional package x11proto-input-dev,
but should depend now on x11proto-dev instead.

libxrandr-dev depends on transitional package x11proto-randr-dev,
but should depend now on x11proto-dev instead.

libxext-dev depends on transitional package x11proto-fixes-dev,
but should depend now on x11proto-dev instead.

libxv-dev depends on transitional package x11proto-video-dev,
but should depend now on x11proto-dev instead.


As far as I know, these are the only packages in Debian testing that
depend on these transitional packages.


This is related to similar report over year ago:

https://bugs.debian.org/926376



Thanks,
Witold


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libxinerama-dev depends on:
ii  libx11-dev2:1.6.9-2+b1
ii  libxext-dev   2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  x11proto-dev [x11proto-xinerama-dev]  2020.1-1
ii  x11proto-xinerama-dev 2020.1-1

libxinerama-dev recommends no packages.

libxinerama-dev suggests no packages.

-- no debconf information

Bug#953555: /usr/bin/glslangValidator: glslangValidator broken with some spirv-tools versions

[Witold Baryluk]

Package: glslang-tools
Version: 8.13.3559-2
Severity: important
File: /usr/bin/glslangValidator

$ glslangValidator 
glslangValidator: error while loading shared libraries: libSPIRV-Tools.so: 
cannot open shared object file: No such file or directory
$

$ ldd `which glslangValidator `
linux-vdso.so.1 (0x7ffcba1f)
libSPIRV-Tools.so => not found
libSPIRV-Tools-opt.so => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fe4b6584000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fe4b63b8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe4b6273000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe4b60b3000)
/lib64/ld-linux-x86-64.so.2 (0x7fe4b6f93000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fe4b6097000)
$

$ dpkg -L spirv-tools | grep lib
/usr/include/spirv-tools/libspirv.h
/usr/include/spirv-tools/libspirv.hpp
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libSPIRV-Tools-link.a
/usr/lib/x86_64-linux-gnu/libSPIRV-Tools-opt.a
/usr/lib/x86_64-linux-gnu/libSPIRV-Tools-reduce.a
/usr/lib/x86_64-linux-gnu/libSPIRV-Tools-shared.so
/usr/lib/x86_64-linux-gnu/libSPIRV-Tools.a
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/SPIRV-Tools-shared.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/SPIRV-Tools.pc
$


$ dpkg -l spirv-tools | egrep ^ii
ii  spirv-tools2019.4-1 amd64API and commands for processing 
SPIR-V modules
$

Updating to spirv-tools 2019.5-1 does fix it tho, so maybe some version
constrain in dependencies of glslang-tools would be useful to have?

Cheers,
Witold


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages glslang-tools depends on:
ii  libc62.29-10
ii  libstdc++6   10-20200222-1
ii  spirv-tools  2019.4-1

glslang-tools recommends no packages.

glslang-tools suggests no packages.

-- no debconf information

Bug#943865: src:mesa: Please build Mesa SWR rasterizer on amd64 and i386

[Witold Baryluk]

Package: src:mesa
Followup-For: Bug #943865


Hi Timo.

I would keep llvmpipe even on x86. Two reasons.

1. Ability to run on SSE2 only hardware
2. SWR do have some bugs compared to llvmpipe which is working almost perfectly.

Having both is also good for testing and benchmarking both as it enables way 
easier switching.

I do not think SWR is in a good shape or have enogh upstream maintainers
to enable by default even on amd64.

Enabling SWR and give time people (including me) to test it more and
compare to llvmpipe is a better idea.


Cheers,
Witold


PS. Sorry if you receive it twice, my reportbug was misconfigured.

Bug#943865: src:mesa: Please build Mesa SWR rasterizer on amd64 and i386

[Witold Baryluk]

Package: src:mesa
Severity: normal

Dear Maintainer,

SWR is a new high performance rasterizer that is usually significantly
faster than softpipe or llvmpipe and is merged in upstream Mesa for
some time.

Adding these meson extra flags:

"-Dgallium-drivers=,swrast,swr" "-Dswr-arches=avx,avx2,knl,skx"

should build and install these files in lib/{x86_64,i386}-linux-gnu/

libswrAVX2.so
libswrAVX2.so.0
libswrAVX2.so.0.0.0
libswrAVX.so
libswrAVX.so.0
libswrAVX.so.0.0.0
libswrKNL.so
libswrKNL.so.0
libswrKNL.so.0.0.0
libswrSKX.so
libswrSKX.so.0
libswrSKX.so.0.0.0

dri/kms_swrast_dri.so(maybe)
dri/swrast_dri.so

It is probably worth packaging into separate package (with all arches
tho, no need to split it into 4 packages, mesa gallium loaader will
automatically determine best suitable version and load it dynamically).

Building on other archs might succeed (unlikely), but it is pointless as
SWR targets at the moment only x86 specific vector instructions so even if
it manages to be able to generate code at runtime (via LLVM) it will not be
able to run it anyway. Thus the request is only for i386 and amd64.

Adding x32 and kfreebsd-{amd64,i386} at your discretion.

Best regards,
Witold.





-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#943777: libdrm-amdgpu1: Please package libdrm 2.4.100

[Witold Baryluk]

Package: libdrm-amdgpu1
Severity: normal

Dear Maintainer,

building newest Mesa from git master as of 2019-10-28 requires libdrm
2.4.100 for building amdgpu related code, but only libdrm 2.4.99 is
available in Debian at the moment.

https://dri.freedesktop.org/libdrm/libdrm-2.4.100.tar.gz

It was release about two weeks ago, it contains minor bug fixes
and improved support for newest hardware.

https://lists.x.org/archives/xorg-announce/2019-October/003028.html

Packaging would be highly appreciated.

Thank you! :)



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#941295: libvulkan1: Please provide debug symbols in -dbgsym package

[Witold Baryluk]

Source: vulkan-loader
Followup-For: Bug #941295
Control: close -1

Please ignore original bug report.
-dbgsym packages are provided for both mentioned packages.
I accidently disabled debug repos on my system.

Bug#941295: libvulkan1: Please provide debug symbols in -dbgsym package

[Witold Baryluk]

Package: libvulkan1
Severity: normal

$ file /usr/lib/x86_64-linux-gnu/libvulkan.so.1.1.121
/usr/lib/x86_64-linux-gnu/libvulkan.so.1.1.121: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=7b02a413d96ddc8829ac8067e4c52a6fcfa110d6, stripped
$

It looks like libvulkan1 is stripped and has no extra debug info. I wish to have
access to it, as it helps with reading some stack traces, and memory leak 
origins
in valgrind for example, and it is helpful when developing Vulkan layers (i.e. 
in
Mesa).

AFAIK all is needed is to simply call dh_strip in rules file. But it is also
possible you need to add -g or similar to compiler flags before building vulkan
loader.

Thanks.

PS. Same applies to shadered libraries vulkan-validationlayers package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#940097: libvulkan-dev: vk_enum_helper uses enum values not defined anywhere

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Severity: important

Trying to use just include it results in an error:

/usr/include/vulkan/vk_enum_string_helper.h: In function ‘string_VkDriverIdKHR’:
/usr/include/vulkan/vk_enum_string_helper.h:3531:14: error: 
‘VK_DRIVER_ID_GOOGLE_PASTEL_KHR’ undeclared (first use in this function); did 
you mean ‘VK_DRIVER_ID_RANGE_SIZE_KHR’?
 3531 | case VK_DRIVER_ID_GOOGLE_PASTEL_KHR:
  |  ^~
  |  VK_DRIVER_ID_RANGE_SIZE_KHR



Regards,
Witold


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvulkan-dev depends on:
ii  libvulkan1  1.1.114.0-1

libvulkan-dev recommends no packages.

libvulkan-dev suggests no packages.

-- no debconf information

Bug#940073: libvulkan-dev: docgenerator module is missing

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Severity: normal

Dear Maintainer,

user@debian:/usr/share/vulkan/registry$ python3 genvk.py  --help
Traceback (most recent call last):
  File "genvk.py", line 25, in 
from docgenerator import DocGeneratorOptions, DocOutputGenerator
ModuleNotFoundError: No module named 'docgenerator'
user@debian:/usr/share/vulkan/registry$

It is not possible to run genvk.py without this module, it should be in sources
same as other files.


PS. Also would be nice if genvk.py had executable bit set please.




*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvulkan-dev depends on:
ii  libvulkan1  1.1.114.0-1

libvulkan-dev recommends no packages.

libvulkan-dev suggests no packages.

-- no debconf information

Bug#939999: libvulkan-dev: Please include manpages for all library functions, structs, extensions

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Followup-For: Bug #93

Just a minor update,

https://www.khronos.org/registry/vulkan/

section 'API Reference Pages' says:

""" In addition to the format published here, it is possible to generate other
formats from the reference page sources, such as PDF or Unix nroff man page
sources. """

I couldn't find the nroff generator in the git repo, but maybe I didn't
search well, (maybe it was removed in master head in git?).

Also, I found out that indeed it is possible, as Arch does ship with vulkan man
pages:


https://aur.archlinux.org/packages/vulkan-man-git/

Examples:

https://manned.org/VkDeviceCreateInfo.3
https://manned.org/vkCreateGraphicsPipelines.3


Sources (not upstreamed fully yet) are in this forked repo:
https://github.com/Ryp/Vulkan-Docs

and some diffs can be seen here:

https://github.com/KhronosGroup/Vulkan-Docs/compare/master...Ryp:master

So, it looks pretty easy. Bulk of the work is done by asciidoctor output plugin,
which is part of official upstream asciidoctor:

https://asciidoctor.org/docs/user-manual/#man-pages

So, there is very little extra work to do beyond maybe adding a small patch to
docs, and adding a package.


Thank you.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvulkan-dev depends on:
ii  libvulkan1  1.1.114.0-1

libvulkan-dev recommends no packages.

libvulkan-dev suggests no packages.

-- no debconf information

Bug#939999: libvulkan-dev: Please include manpages for all library functions, structs, extensions

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Severity: wishlist


The upstream do have both a general Vulkan spec text plus all the
functions description, but the functions and structures / types
documentation is also available as "manual pages", i.e.

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkGetPhysicalDeviceFeatures.html

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCreateDisplayModeKHR.html

etc.

It can also be found via this page:

https://vulkan.lunarg.com/doc/sdk/1.1.114.0/windows/apispec.html

where they are kind of bundled together.

They already look man-like to me.

These are all generated afaik from common source somewhere, and should be
very easy to generate nroff (or troff/groff) / man files and include in
the package. PS. Make sure they are compressed. man supports .Z, .z and
.gz, and automatically decompresses them. (I have 18380 .gz files in my
/usr/share/man directory, and zero uncompcressed files).

I think this is the source for all these docs, both a specification and
man pages:

https://github.com/KhronosGroup/Vulkan-Docs

It appears that most of the documentation and spec is written in
asciidoctor, and could be transformed to proper format.

I am not sure where exactly the text for this html pages comes from, as
they contain way more descriptions than just what is in the registry
/usr/share/vulkan/registry/vk.xml , which only provide short comments for
each member of struct or argument, but not full documentation and
explanation of semantics, or valid usages. In fact the registry doesn't
provide any comments or descriptions about functions, only about fields
in types (structs).

AFAIK, it would be fine to bundle these man pages in libvulkan-dev
package, without needing separate package.

With possibly separate libvulkan-doc for the full spec text, tutorials
and examples from SDK.

Similar generated docs:

https://devdocs.io/vulkan/
https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch04s01.html

Any way, considering how complex and explicit the spec is, with its
number of input, output structs, functions and extensions, it make sense
to have it more accessible from terminal (or other man viewer or IDE that
can link to man pages) quickly without using Internet or Google. ;)

Cheers,
Witold



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvulkan-dev depends on:
ii  libvulkan1  1.1.114.0-1

libvulkan-dev recommends no packages.

libvulkan-dev suggests no packages.

-- no debconf information

Bug#939301: /usr/bin/vulkaninfo: html output is not correctly formated. Not closed VkPhysicalDevicePCIBusInfoProperties section.

[Witold Baryluk]

Package: vulkan-tools
Version: 1.1.114.0+dfsg1-1
Severity: normal
File: /usr/bin/vulkaninfo

Dear Maintainer,

when using `vulkaninfo --html`, the resulting vulkaninfo.html do have a
bug, leading to incorrect rendering of the result file in the browser:

"""
...

VkPhysicalDevicePCIBusInfoProperties
pciDomain   = 
0
pciBus  = 
67
pciDevice   = 
0
pciFunction = 
0


VkPhysicalDeviceTransformFeedbackProperties

"""

Clearly there should be , at the end of the
VkPhysicalDevicePCIBusInfoProperties section, before a new section about
VkPhysicalDeviceTransformFeedbackProperties is started.

AFAIK, this is the only section in the html report with this issue. Other
ones looks to be correctly closed and indented too.

PS. It would be nice if "Format Properties" section is split into
supported and unsupported parts, just like the text output report of
vulkaninfo.


Cheers,
Witold




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vulkan-tools depends on:
ii  libc6   2.28-10
ii  libgcc1 1:9.2.1-4
ii  libstdc++6  9.2.1-4
ii  libvulkan1  1.1.114.0-1
ii  libwayland-client0  1.17.0-1
ii  libx11-62:1.6.7-1
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2

vulkan-tools recommends no packages.

vulkan-tools suggests no packages.

-- no debconf information

Bug#658636: Acknowledgement (xserver-xorg-video-radeon: Multiple DRI regressions)

[Witold Baryluk]

Ok,

I managed to fix my computer.

It was not a problem in Xorg, DDX or udev at all.

It is kernel problem, and in my particular case a module loading done by 
initramfs.

It looks that initramfs-tools, was loading radeonfb module before
another ones, in early bootup process, and this messed with drm stuff
(drm and radeon module) for some reason. Initramfs was loading this
module early because I added 'radeonfb'  entry to the
/etc/initramfs-tools/modules long time ago, but it was not working or
was not an issue. Now it started to be issue. In fact I belive I hit
exactly same problem when I was compiling kernel with radeonfb and
radeon built-in directly into kernel. Modules was loading probably in
wrong order or something.

It was not udev fault. After booting, there was not even a proper
'card0' files in /sys/ tree. Removing 'radeonfb' from early boot loading
from initramfs, resolved problem for me.

So it looks that it is some problem beetween radeonfb and radeon modules.

In fact I do not have radeonfb module loaded right now, but I still have
a highresolution framebuffer on the console and /dev/fb0 exists, so I am
somehow confused how is this possible!

# dmesg | grep fb
[5.157160] device: 'fbcon': device_add
[5.157218] PM: Adding info for No Bus:fbcon
[  118.948689] [drm] fb mappable at 0xC00C
[  118.948848] [drm] fb depth is 24
[  118.949031] device: 'fb0': device_add
[  118.978424] PM: Adding info for No Bus:fb0
[  118.978936] fbcon: radeondrmfb (fb0) is primary device
[  119.549784] fb0: radeondrmfb frame buffer device


So why there are two incompatible drivers, especially when radeon looks
to be providing framebuffer anyway? Is radeonfb module supporting even
some older hardware so it is keeped in kernel?

Maybe maintainers of Xorg will have better knowledge about this
radeon/radeonfb mess, than Kernel maintainers before reassigning or
closing bug.


Regards,
Witek

-- 
Witold Baryluk



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120208003239.gb7...@smp.if.uj.edu.pl

Bug#656375: libdrm-intel1: screen corruptions, kernel message "*ERROR* Prepared flip multiple times"

[Witold Baryluk]

On 01-19 01:18, Cyril Brulebois wrote:
> Hi,
> 
> Witold Baryluk  (18/01/2012):
> > After logging into GNOME, I started getting LOTS of
> > [  239.494761] [drm:intel_prepare_page_flip] *ERROR* Prepared flip multiple
> > times
> > in kernel log repeated ever few microseconds.
> > 
> > Lots of GNOME elements is missing (they are still there, but not
> > drawned), like some menus, some font glyphs. It is clearly regression,
> > because just month ago everything was working.
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated 
> > Graphics
> > Controller (rev 02)
> 
> that's apparently a gen2 card, as in “very old”, and upstream suggests
> such a setup won't help run GNOME at all. Newer hardware or different
> desktop environment I guess? :-/ Good luck.
> 
> Upstream bug report:
>   http://bugs.freedesktop.org/41793
> 
> Mraw,
> KiBi.


This is regression, thus I report it. Everything was working find about
month ago. This is clearly a driver problem, not a hardware problem!

This is not "very old", rather just "old" (Q2'04). I was able to run smoothly
gnome shell on similary old other intel chip (915GM, from Q1'05) in
laptop. Strange that similary equiped desktop chipset cannot do the same
(I can play in many 3D games on it without much problem). For me old is
something more like pre-2000. ;)


Thanks,
Witek

-- 
Witold Baryluk



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120121082813.ga31...@smp.if.uj.edu.pl

Bug#656375: libdrm-intel1: screen corruptions, kernel message "*ERROR* Prepared flip multiple times"

[Witold Baryluk]

Package: libdrm-intel1
Version: 2.4.30-1
Severity: important

Hi,

After logging into GNOME, I started getting LOTS of
[  239.494761] [drm:intel_prepare_page_flip] *ERROR* Prepared flip multiple
times
in kernel log repeated ever few microseconds.

Lots of GNOME elements is missing (they are still there, but not drawned), like
some menus,
some font glyphs. It is clearly regression, because just month ago everything
was working.

lizander:~> uname -a
Linux lizander 3.1.0-1-686-pae #1 SMP Tue Jan 10 05:42:54 UTC 2012 i686
GNU/Linux
lizander:~> lspci  | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics
Controller (rev 02)
lizander:~> glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 1.3 Mesa 7.11.2
lizander:~>

ii  libgl1-mesa-dri 7.11.2-1
free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx 7.11.2-1
free implementation of the OpenGL API -- GLX runtime

ii  xserver-xorg1:7.6+10
X.Org X server
ii  xserver-xorg-core   2:1.11.3.901-1
Xorg X server - core server
ii  xserver-xorg-video-intel2:2.17.0-1
X.Org X server -- Intel i8xx, i9xx display driver

Machine is IBM ThinkCentre (MT-M: 8183-QGP):
http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-51078
http://support.lenovo.com/?lndocid=MIGR-51266


Thanks,



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libdrm-intel1 depends on:
ii  libc6  2.13-24
ii  libdrm22.4.30-1
ii  libpciaccess0  0.12.902-1
ii  multiarch-support  2.13-24

libdrm-intel1 recommends no packages.

libdrm-intel1 suggests no packages.

-- debconf-show failed



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120118212210.2881.67159.report...@lizander.kolo.smp.if.uj.edu.pl

Bug#651399: xdmx crashes on GLX requests

[Witold Baryluk]

Package: xdmx
Version: 2:1.11.2.901-1
Severity: important

Dear Maintainer,


running any glx app, even glxinfo, or glxgears
makes whole xdmx crash.

Also trying running mplayer with -vo xv, or -vo gl
make xdmx crash. (mplayer -vo x11 works, but extremally
slowly)

I have standard X server running on 10.0.2.5 and 10.0.2.5,
with gdm3 config change to make X listen on TCP.

After logging on two machines, and disabling authirozation
by xhost + on both, I started from one of machine (10.0.2.5):

startx `which twm` -- \
  /usr/bin/Xdmx :1  \
  -display 10.0.2.5:0  \
  -display 10.0.2.8:0  \
  -ignorebadfontpaths \
  +xinerama


Then running glxinfo, make xdmx crash.


10.0.2.5 have nvidia geforce 8600 GT, with nvidia 290
drivers (GLX and XV works on Xorg without xdmx).
It is 32-bit OS.


10.0.2.8 is another machine, also with nvidia, but 7600,
and different drivers. 10.0.2.8 is 64-bit OS.

Is GLX working for anybody? Do I need to have same graphics cards
in each machine to have GLX working properly?

I also tried xdmx with single backend server (10.0.2.5),
and in fact effec was the same;




tytus:~> ./go_xdmx

(II) dmx: Generation: 1
(II) dmx: DMX version:1.2.20070424 (DMX Project)
(II) dmx: DMX Build OS:   Linux 2.6.32-5-686-bigmem i686 (Debian)
(II) dmx: DMX Build Compiler: gcc 4.6.2
(II) dmx: DMX Execution OS:   Linux 3.2.0-rc4+ #8 SMP Thu Dec 8 10:38:35 CET
2011
(II) dmx: DMX Execution Host: tytus
(II) dmx: MAXSCREENS: 16
(II) dmx: Using configuration from command line
(II) dmx: Added 10.0.2.5:0 at 0 0
(II) dmx[o0/10.0.2.5:0]: Name of display: 10.0.2.5:0
(II) dmx[o0/10.0.2.5:0]: Version number:  11.0
(II) dmx[o0/10.0.2.5:0]: Vendor string:   The X.Org Foundation
(II) dmx[o0/10.0.2.5:0]: Vendor release:  11102901
(II) dmx[o0/10.0.2.5:0]: Dimensions:  1280x1024 pixels
(II) dmx[o0/10.0.2.5:0]: 7 depths on screen 0:  24,1,4,8,15,16,32
(II) dmx[o0/10.0.2.5:0]: Depth of root window:  24 planes (24)
(II) dmx[o0/10.0.2.5:0]: Number of colormaps:   1 min, 1 max
(II) dmx[o0/10.0.2.5:0]: Options: backing-store no, save-unders no
(II) dmx[o0/10.0.2.5:0]: Window Manager running: yes
(**) dmx[o0/10.0.2.5:0]: Window manager running -- colormaps not supported
(II) dmx[o0/10.0.2.5:0]: 1280x1024+0+0 on 1280x1024 at depth=24, bpp=32
(II) dmx[o0/10.0.2.5:0]: 0x21 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
*
(II) dmx[o0/10.0.2.5:0]: 0x22 DirectColor 24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x24 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x25 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x26 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x27 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x28 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x29 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2a TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2b TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2c TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2d TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2e TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x2f TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x30 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x31 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x32 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x33 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x34 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x35 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x36 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x37 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x38 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x39 TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3a TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3b TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3c TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3d TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3e TrueColor   24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x3f DirectColor 24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x40 DirectColor 24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x41 DirectColor 24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x42 DirectColor 24b 8b/rgb 256 0xff 0xff00 0x00ff
(II) dmx[o0/10.0.2.5:0]: 0x43 DirectColor 24b 8b/rg

Bug#370088: x11-common: Should also conflicts with gv (<=1:3.5.8-26.1)

[Witold Baryluk]

Package: x11-common
Version: 1:7.0.22
Followup-For: Bug #370088

gv 3.5.8-26.1 contain /usr/X11R6/bin/gv , so similary this package
should conflicts (so upgrade will be easier).



signature.asc
Description: Digital signature