Bug#1075844: xserver-xorg-video-fbdev: ./revert-ae0aeffae665746.diff in source package

2024-07-06 Thread Tj
Package: xserver-xorg-video-fbdev Version: 1:0.5.0-2 Severity: minor X-Debbugs-Cc: tj.iam...@proton.me Whilst researching a bug in other packages and inspecting how fbdev interacts with them I found the source package (.diff.gz) fetched with dget contains the file ./revert-ae0aeffae665746.diff I

Bug#1041647: Stepping back and checking basics

2023-07-21 Thread Tj
vainfo: VA-API version: 1.17 (libva 2.12.0) vainfo: Driver version: Mesa Gallium driver 22.3.6 for VERDE (, LLVM 15.0.6, DRM 2.50, 6.5.0-rc2+debian+tj+) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main

Bug#1041647: Stepping back and checking basics

2023-07-21 Thread Tj
:00.0: disabling GPU acceleration $ uname -r 6.4.3+debian+tj+

Bug#1041647: Further gdb debugging (more #2)

2023-07-21 Thread Tj
After solving the relative path issue I now have better info: (gdb) s __vaDriverInit_1_17 (ctx=0x555702b0) at ../src/gallium/frontends/va/context.c:123 123if (!ctx) (gdb) n 126drv = CALLOC(1, sizeof(vlVaDriver)); (gdb) n 127if (!drv) (gdb) n 130switch (ctx->d

Bug#1041647: Further gdb debugging (more)

2023-07-21 Thread Tj
The mesa-va-drivers-dbgsym package seems to have incorrect (relative to build) paths stored which prevents gdb showing the source lines when it has the path to the mesa-22.6.3 source, however by blindly stepping and then looking at the source it narrows down the cause: (gdb) s 126 in ../sr

Bug#1041647: Further gdb debugging

2023-07-21 Thread Tj
Using export LIBVA_MESSAGING_LEVEL=2; export LIBVA_DRIVER_NAME=radeonsi; gdb --directory . --directory ../libva-2.17.0 --directory ../mesa-22.3.6 --args /usr/bin/vainfo I've stepped through vainfo and focused on va_openDriver() which eventually leads to: (gdb) n libva info: Found init functi

Bug#1004154: Fwd: Bug#1004154: xserver-xorg-video-qxl: XOrg frequently crashes when using qxl driver: qxl(0): error doing QXL_ALLOC

2022-10-21 Thread TJ
On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote: I noticed that vgamem_mb was still low (32 MB). So I changed to this (slightly wasteful) command-line and am now running the latest kernel (5.15.0-3-amd64): -vga none -device qxl-vga,ram_size_mb=256,vgamem_mb=256,vram_size_mb=256,vram64

Re: Bug#268120: Adpot Windows conventions for producing International Characters

2004-08-26 Thread TJ
David Wright wrote: > >> What does it have to do with gnome-applets-data? > > dpkg -S /usr/share/xmodmap/xmodmap.us returns gnome-applets-data. Do you > not own these xmodmaps? > >> I don't see the point here. Why making things so complicated when there >> is a simple way to do it (Multi_key) ?

Re: Bug#258612: xlibs: want gb variant of dvorak and pc/dvorak

2004-08-19 Thread TJ
Branden Robinson wrote: > > It would be nice to have a picture of a UK Dvorak keyboard. > I thought my post was lost to the ether and I just been made aware of this post. I was never ever emailed anything reguarding this. heres a picture http://prdownloads.sourceforge.net/ninemenmorris/kb.jpg

UK Variant dvorak

2004-07-02 Thread TJ
Hi would you consider adding the following to /usr/X11R6/lib/X11/xkb/symbols/dvorak and /usr/X11R6/lib/X11/xkb/symbols/pc/dvorak //UK Dvorak partial alphanumeric_keys xkb_symbols "gb" { include "dvorak(basic)" key {[ grave, notsign ], [