Re: alacritty: possible inputmethod issue?

On Sun, 20 Jun 2021 at 11:26, Chavdar Ivanov <[email protected]> wrote:

>
> On 6/20/21 10:37 AM, Thomas Klausner wrote:
> > On Sun, Jun 20, 2021 at 11:22:38AM +0200, Tobias Nygren wrote:
> >> On Sun, 20 Jun 2021 11:00:28 +0200
> >> Thomas Klausner <[email protected]> wrote:
> >>
> >>> On Sun, Jun 20, 2021 at 10:52:49AM +0200, Tobias Nygren wrote:
> >>>> On Sun, 20 Jun 2021 15:50:04 +0900
> >>>> iquiw <[email protected]> wrote:
> >>>>
> >>>>> I have a workaround fix of the problem and also prepared a sample C
> >>>> Thanks! I went ahead and added the workaround patch to pkgsrc for now.
> >>>> So people who experienced the problem please try alacritty-0.8.0nb1?
> >>>> The problem should still be addressed in the base system.
> >>> Thank you!
> >>>
> >>> But I get a coredump on startup now:
> >>>
> >>> (gdb) bt
> >>> #0  pthread_mutex_lock (ptm=0x10) at
> /disk/6/archive/foreign/src/lib/libpthread/pthread_mutex.c:204
> >>> #1  0x0000701cd5e6a06d in mtx_lock (mtx=<optimized out>) at
> /disk/6/archive/foreign/xsrc/external/mit/MesaLib/dist/include/c11/threads_posix.h:223
> >>> #2  _mesa_HashLockMutex (table=<optimized out>) at
> /disk/6/archive/foreign/xsrc/external/mit/MesaLib/dist/src/mesa/main/hash.h:131
> >>> #3  create_shader (ctx=0x701ce4d16880, type=35633) at
> /disk/6/archive/foreign/xsrc/external/mit/MesaLib/dist/src/mesa/main/shaderapi.c:339
> >>> #4  0x000000007ad6cf0e in alacritty::gl::CreateShader () at
> /scratch/x11/alacritty/work/alacritty-0.8.0/target/release/build/alacritty-ea65f179719708c6/out/
> gl_bindings.rs:1106
> >>> #5  alacritty::renderer::create_shader () at alacritty/src/renderer/
> mod.rs:1096
> >>> #6  0x000000007ac69825 in alacritty::main () at alacritty/src/renderer/
> mod.rs:981
> >> Maybe RTLD global binding has unfortunate side effects for pthread.
> >>
> >> I wonder if it would work instead to link the binary explicitly
> >> with -lX11. Try this patch?
> > No, then I'm back to the previous error.
> >
> > thread 'main' panicked at 'Failed to open input method:
> PotentialInputMethods {
> >      xmodifiers: None,
> >      fallbacks: [
> >          PotentialInputMethod {
> >              name: "@im=local",
> >              successful: Some(
> >                  false,
> >              ),
> >          },
> >          PotentialInputMethod {
> >              name: "@im=",
> >              successful: Some(
> >                  false,
> >              ),
> >          },
> >      ],
> >      _xim_servers: Err(
> >          GetPropertyError(
> >              TypeMismatch(
> >                  0,
> >              ),
> >          ),
> >      ),
> > }',
> /scratch/x11/alacritty/work/vendor/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:134
> :17
> > note: run with `RUST_BACKTRACE=1` environment variable to display a
> backtrace
>
>
> As I wrote above, I am running alacritty 0.8.0 on real hardware with
> Intel 530 graphics - mind you, under Gnome 4.0 even... It seems to be
> working *almost* fine. It could be something to do with the early Gnome
> 4.0 or an OS issue - the echo from the characters input comes not after
> each character typed, but awaits for the next character to be sent, it
> is not very easy to explain.


This happens only under gnome 4.0, under xfce4 appears fine.


>
>
> The system is:
>
>
>   Host        -  xci@tarkus
>    Machine     -  HP HP ENVY Notebook Type1ProductConfigId
>    OS          -  NetBSD 9.99.85
>    DE          -  GNOME
>    WM          -  GNOME Shell
>    Packages    -  2318 (pkgsrc)
>    Local IP    -  192.168.0.35
>    Resolution  -  1920x1080
>    Terminal    -  alacritty
>    Shell       -  Zsh
>    Uptime      -  34 minutes
>    CPU         -  Intel® Core™ i7-6700HQ CPU @ 2.60GHz (8)
>    CPU%        -  15%
>    Memory      -  3.6 GB/16.1 GB
>    Battery     -  Full
>
> Initial comparisons with other terminal emulators don't show any
> particular speed advantage, though (just naive 'time cat
> /usr/share/dict/words').
>
>
> Chavdar
>
>
>
> >   Thomas
>
-- 
----