Gnome/Mate terminal maximized by default

adrozdoff@gmail.com (Alexander Drozdov) — Fri, 09 Nov 2018 00:00:00 +0000

…In case, when Compiz is used as Window Manager.

With Compiz

I use Mate and Compiz as Window manager. According information from the Internet, there is only one way to run Gnome Terminal (and any derivative terminals, like Mate Terminal): run it with option --maximize. Better solution implemented in KDE Terminal - Konsole, it just save last window geometry.

Command line option good… But… you should point it everywhere where terminal runs: menu entries, shortcuts, application settings where terminal pointed… There is no way to point such option for application runs in terminal.

So, solution: use ability of WM to apply window attributes according some window properties (look into xprop).

Compiz allow to maximize all windows by default, or apply layout settings selective. Just run ccsm and go to Windows Management -> Place Windows -> Fixed Window Placement. After that, look into Windows with fixed placement mode and click New:

Type class=Gnome-terminal to the Window field and select Maximized in Mode field:

Now, Gnome terminal windows will be handled by Compiz and maximized by default.

Same can be done by Windows Rules plugin. Just enable it, open settings and in Maximized matches type class=Gnome-terminal:

For Mate Terminal or some other, observe window class via xprop.

With Devilspie2

Another way, use Devilspie, or same tools:

Solution that work in Cinnamon, GNOME, Mate and other DE with devilspie2: put to the ~/.config/devilspie2/gnome-terminal.lua next code:

if (get_window_class() == "Gnome-terminal") then
    maximize();
end

Read more about allowed functions: https://git.savannah.gnu.org/cgit/devilspie2.git/plain/README.

Add devilspie2 to auto start. To apply without re-login: Alt+F2 and type devilspie2. Action will be applied to the existing Terminal windows and to the newly created.

Why may Linux driver developers hate distros like CentOS?

adrozdoff@gmail.com (Alexander Drozdov) — Tue, 12 Jun 2018 00:00:00 +0000

A recent incident from my life.

Deal with CentOS 7.5. Base kernel for it - 3.10.0. Keep it in mind.

CenOS kernel 3.10.0-862 contains back ported ALSA stack from newer kernels. New stack discards snd_card_create call and replace it with snd_card_new that mostly same, but put additional argument to the front of parameters:

int snd_card_create(                       int idx, const char *xid, struct module *module, int extra_size, struct snd_card **card_ret)
vs
int snd_card_new   (struct device *parent, int idx, const char *xid, struct module *module, int extra_size, struct snd_card **card_ret);

(arguments aligned by me)

But, a lot of internal drivers still refer to the old snd_card_create and CentOS maintainers adds next hack:

static inline int __deprecated
snd_card_create(int idx, const char *id, struct module *module, int extra_size,
        struct snd_card **ret)
{
    return snd_card_new(NULL, idx, id, module, extra_size, ret);
}

that just wrap snd_card_new and pass NULL as a first argument.

But it is wrong. Because snd_card_new contains next line:

int snd_card_new(struct device *parent, int idx, const char *xid,
		    struct module *module, int extra_size,
		    struct snd_card **card_ret)
{
...
	card->dev = parent; // [1]
...
	snprintf(card->irq_descr, sizeof(card->irq_descr), "%s:%s",
		 dev_driver_string(card->dev), dev_name(&card->card_dev));
...
}

nothing wrong for a first look. But… I see next call:

dev_driver_string(card->dev)

Look to the [1], card->dev just a NULL. Refer to the dev_driver_string, it is simple function:

const char *dev_driver_string(const struct device *dev)
{
        struct device_driver *drv;

        /* dev->driver can change to NULL underneath us because of unbinding,
         * so be careful about accessing it.  dev->bus and dev->class should
         * never change once they are set, so they don't need special care.
         */
        drv = ACCESS_ONCE(dev->driver);
        return drv ? drv->name :
                        (dev->bus ? dev->bus->name :
                        (dev->class ? dev->class->name : ""));
}

Note, dev here is NULL. And in all lines of this function NULL is dereferencing!

Now look into our driver. We use old ALSA API for kernels less than 3.15.0 and new one for any newest. Base kernel version for CentOS is 3.10. So, we select old API call. And when our driver is loaded, kernel moves to the Panic.

So, we should do additional check like:

#ifdef RHEL_RELEASE_CODE
#  define HAVE_SND_CARD_NEW (RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,5))
#else
#  define HAVE_SND_CARD_NEW (LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0))
#endif

#if HAVE_SND_CARD_NEW
    // use new API here
#else
    // use old API here
#endif

Same ugly things also doing by OpenSUSE maintainers. But in additional, thay does not provide way to self-detection similar to RHEL_RELEASE_CODE. At all.

Posts on Hatred's Log Place

Gnome/Mate terminal maximized by default

With Compiz

With Devilspie2

Why may Linux driver developers hate distros like CentOS?